What do you think? Will the JVM ever get support for generics?
Quite likely that would not only require substantial changes to the JVM, but also to the class file format,
but languages running on the VM would greatly benefit from it.
Edit: The Java language actually supports some sort of generics as a compile time feature, which adds some casts to the bytecode, which people had to add manually before.
The decision to not introduce changes to the JVM or the class file specification was well understood at these times, because they didn't want to break backward-compatibility and Java was the only significant language for the JVM these days.
While this decision might have been appropriate for the Java language, it has significantly reduced the amount of freedom other languages have to choose how they want to implement generics on the VM.
Considering that Sun/Oracle have proclaimed to make the JVM a friendlier place for alternative languages, will they actually do what they promised or consider they that the low cost addition of "InvokeDynamic" is enough?
In my opinion it is unlikely.
It would simply be too disruptive to apply these changes to the Java language. Linguistic and runtime backwards compatibility with two different models of generics would be a nightmare for the designers.
And without, Java to drive changes to the JVM, it is hard to see how Oracle would / could justify doing the work required.
The only possibilities I see are:
Oracle decides to develop a successor language to Java (that is not backwards compatible) that does generics, closures and a whole bunch of things better. That would be a really brave business decision, and I don't think Oracle is capable of making it.
A bunch of other people / companies get together and fork the JVM specification and the codebase. That's also a brave move to make.
I don't think it is likely that Oracle would resource a major change to the JVM just to support languages that they had no commercial interest in. We are talking about here Oracle ... where the business types have a much tighter control over what the engineering types get to do than in the dying Sun days. (Hey ... we could start a whole Jack Vance theme going here :-)
Related
JSR-335 is said to come soon along with Java 8. It brings i.e. support for closures and virtual extension methods.
I wonder if there is any particular support for this on the JVM level?
If so, can we hope for speed improvements in JVM-based functional languages that provide closures and extension-methods-like features (such as traits or implicits in scala)?
Edit:
reading this oracle presentation on Java 8 by Brian Goetz, it would appear that:
- closures don't require
- virtual extension methods do require
particular JVM-support.
Could this mean that in scala, some of the implicits, and traits could be reimplemented in a more efficiently way?
I don't think extension methods can be used to implement traits -- a method implementation can't call super on them (afaik -- I might be wrong), and the override semantics would be different. Furthermore, it would not cover fields, just methods.
There isn't anything JVM can do to help with implicits, because there's no inherent problem with them. They are normal instances passed as normal parameters. Looking them up makes the compiler slow, but JVM can't help with that either.
I don't see any of these features helping with anything in Scala, but that's almost moot, actually. Scala still generates JVM 1.5 bytecode with JVM 1.5 classfiles. You can turn on JVM 1.6 bytecode, which makes little difference. With Scala 2.10, 1.6 classfiles will be enabled on an experimental basis.
The reason for that is pretty simple: Java 1.7 runs 1.5 classfiles with 1.5 bytecode, but not the other way around. There's still a lot of people running older versions of Java, and that is unlikely to change.
So I don't see any Java 1.8 features in the radar, unless they bring a huge advantage. And, even then, they'll most likely be available for code compiled with Scala, but not on the Scala library itself. Likewise, unless it brings a huge advantage, I don't see libraries being made available in both versions.
I think the speed of Scala is very close to Java already. It is the dynamic typed jvm languages are slow (such as Groovy). And actually JDK 7 came out with the new feature invokedynamic for the purpose of improve those dynamic jvm language:
http://java.sun.com/developer/technicalArticles/DynTypeLang/
The question may at first sound silly, but maybe it isn't at all.
Java is not the Java language, most people know that, since you can program Java with lots of other langauges like Scala or Groovy
Java is not a concrete VM implementation since there are other implementation out there, not only SUN's, Microsoft's or IBM's.
Java is not the class framework since many implementation add or leave out classes at will.
It isn't even that a common VM specification or even Java bytecode must be used, see Dalvik VM
Maybe it is just a set of principles they share, whatever this may be. It definitely is not "Write once, run everywhere" since this isn't the case for at least Dalvik and Microsoft VM/J#.
So the question is, what exactly is Java? Is there even an exact definition?
EDIT
Lots of people seem to have the opinion that java only means the programming language. So a java-enabled mobile phone must be a phone which enables the user to use programs consisting of class files created with the java language only. If this would be true, the java virtual machine / java runtime environment / java development kit would be made for java only and other jvm languages would have their own corresponding xvm / xre / xdk.
Java is the Java language, actually. Groovy, Scala et al compile down to equivalent bytecode that can run on the JVM, but they aren't Java.
Formally, I'd say that Java is the JLS.
Java is a programming language. The syntax part.
In my opinion it's the language. I don't think people say they're programming Java with Groovy, or if they do, they are being inaccurate.
Strictly speaking Java is just a programming language. But it's a programming language that includes many, many standards: for example many API’s and JVM specifications. That's why SUN and others refer to it as a platform.
Other languages like Scala, Ruby, etc. are not Java, they just compile to byte code that runs in a Java Virtual Machine. They are just build on top of the Java platform, but are themselves not Java.
The JVM is highly standardized and many companies can and do offer their own implementations for their hardware platforms. This is not Java either, these are just implementations of a part of the Java platform.
The Java VM specification is 100% standardized something that is enforced by Oracle as they claim copyright on Java. That’s why the Android (Dalvik VM) is currently the subject of a court case of Oracle against Google.
Actually, it depends on the context where the word is used. It's all: syntax, technology, framework, programming language.
As a sidenote, Oracle answers this question as follows: What is Java?
You cannot say that Scala is Java any more than you can say that a fork is a comb just because you happen to be brushing your hair with it. Or, if I may bring up the classic analogy, driving nails with your wrench doesn't make it a hammer.
You can make a compiler that compiles COBOL into C++ if you want, but that doesn't mean COBOL is C++.
Many languages have x86 machine code as their target compiled language, so does this mean they are all the same thing?
It doesn't matter if other languages can compile to the JVM's bytecode, nor does it matter that you can compile Java into a specific architecture's machine code. The JVM is still Java's platform; other languages just happen to share it, and Java just happens to be able to compile to targets other than JVM bytecode. The same way as a fork just happens to be able to comb your hair depending on how you handle it.
I think this is a silly question (and has nothing to do with programming besides). Is it possible for someone to act like a renaissance philosopher and try to argue that your fork is actually a comb because you have never, ever used it as a fork and always use it only in your hair? Sure, go ahead and argue, and maybe you'll even have a point, but hopefully nobody wastes their time listening to it. This is all just a game of semantics, and once you start arguing about semantics everybody loses.
(edit)
Bah! I just realized I'm arguing about semantics!
Most people see Java as the programming language (as defined by the Java Language Specification). But there are plenty of others who split it into the Programming Language, the various VMs and the larger ecosystem.
There are also legal definitions of what can be called Java (e.g. The trademark), but I think I'm going to leave that one alone at the moment :-)
What is their official position towards clojure?
Why should Sun/Oracle (as a whole), empoyees, or any of the millions of users of said Java libraries or JVM care about Clojure except how Clojure is beneficial (or detrimental) to individual tasks?
The question is, well, silly at best.
Clojure will not replace Java -- it was not even designed to -- and, if anything, simply showcases the adaptability of the JVM (and the layers of hacks used to support dynamic languages in relatively efficient ways). Hopefully the JVM will flourish and improve (and will have better support for "non-Java" programming models).
There is no reason at all why sun might be "not too excited" about alternative JVM languages (and there are lots of languages besides Clojure: Groovy, Scala, JRuby, Jython, even JavaFX which is from Sun itself).
I think all those new languages are important for the JVM, and Sun is actively working on adding support in the JVM for alternative programming languages (see JSR 292, for example).
It's not like as if Sun wants everybody to use the Java programming language only...
Sun is not a single mind. You will find opinions on clojure that are all over the map:
http://www.google.com/search?source=ig&hl=en&rlz=&q=site%3Ablogs.oracle.com+clojure&aq=f&oq=&aqi=
And don't forget, a lot of non-Java languages running atop the JVM can take advantage of those vast libraries, both within the JDK and without. I think Sun generally approves of such reuse.
I don't know of any "official" position of Clojure. You may have seen reports of work on supporting dynamic languages on the JVM and hosting JVM language summits at the Santa Clara campus. The general attitude seems to be, if you want to do some programming, please come and do it on the JVM.
The most optimistic success case for Clojure is probably defined relative to the other Lisp variants. Should Clojure lead the Lisp army (unlikely, BTW, but that's another question) it still would not have much economic effect.
And if it doesn't have much economic effect, then it won't really have a conventional wisdom inside a corporation. Individuals there will like it and dislike it, but as a company, they just won't care one way or another.
Should hell freeze over and then everone starts developing in Clojure, the company probably still wouldn't care, they would just find a way to adapt and live in the new ecosystem. As time went on a story would develop about how it was all their idea to start with.
Where do JVM Implementations differ (except licensing)?
Does every JVM implement Type Erasure for the Generic handling?
Where are the differences between:
JRockit
IBM JVM
SUN JVM
Open JDK
Blackdown
Kaffe
.....
Deals one of them with Tail-Call-Optimization?
JVM implementations can differ in the way they implement JIT compiling, optimizations, garbage collection, platforms supported, version of Java supported, etc. They all must meet set of features and behaviors so that it will execute your Java bytecodes correctly.
As you've pointed out, the major difference tends to be in licensing. Other non-technical differences tend to be in free/paid support options, integration with other technologies (usually J2EE servers), and access to source code.
Note: While a J2EE server runs on the JVM, some servers have integrated tools for monitoring, analyzing, and tweaking JVM performance.
As far as technical differences, those have grown less significant over the years. Once upon a time, the IBM and JRockit JVM's had far superior performance to the reference Sun implementation. This was due to significant differences in the types of runtime optimizations, differences in garbage collection, and differences in native-code (and how much native code various classes uses). These performance differences aren't as significant anymore.
Some JVM's also include or integrate with diagnostics and monitoring tools. JRockit includes a set of tools for monitoring your JVM performance. Sun provides various JMX-based tools with overlapping features to do the same. IBM Websphere once upon a time included a similar set of tools for their whole J2EE application server (not sure if they still do, but I would assume that's still true)...
Some of the open source JVM's tend to have a little slower performance because they have been redeveloped from the ground up. As such, they've got a bit more catching up to do. Last I checked about 2 years ago, Blackdown was significantly slower (1.5x-2x?) than the Sun JVM. It was also a bit behind of supported versions of Java.
Type erasure is a compiler function and as such JVM independent.
Things like type erasure are done by the compiler to be backward compatible with older JVMs. Most JVMs should support all the features you need, but some may be more optimized than others. I'm guessing the Sun JVM is probably the fastest.
JIT compiling is one thing that some JVM:s don't have.
If the JVM claims to be Java it must pass the TCK, providing a lot of stock funcitonaltiy.
The differences are in non-core places, like garbage collection, the jconsole/visualvm in the Sun JVM, precompilation etc.
clarification: TCK is the test suite that a virtual machine has to pass in order to be officially Java compliant.
Another difference between JVMs is behaviour on undocumented API. (e.g. com.sun.xxx)
For example, Sun's JVM and IBM's JVM both have slightly different behaviour on signal handling. (IBM's JVM doesn't allow the application to trap the "INT" signal in certain cases.)
JVM is like a virtual Machine that works to Load the class and Bytcode varifier, execute the code. while Applocaion Programming Interface is Collection of Packages. and Packages are collection of class. Java program execute where JVM Installed and Works.
Tail-call optimization is not yet supported by Java. John Rose is leading efforts to include this in a future release, and has described the approach, and some of the issues involved.
I've had little exp. with java and since now i've worked with c++. what makes this one more special and preferred?
Moreover I would like to know about the use of System.in classes and parseInt classes.
Java is vastly easier to work with, especially when developing large programs.
Debugging: Java generates nice Stacktraces
Stability: You can catch every exception
Development Speed: you need no linker (which can take many minutes in C++); with a modern IDE (e.g. eclipse) you can edit code in-place while the program is running
Garbage Collection and run-time type safety eliminate whole classes of errors
really good free (as in beer) IDEs
In theory (and sometimes in reality) Java programs also run on multiple platforms, "write once - debug, er, run everywhere" type of thing. That makes it very useful for a variety of projects.
In my personal experience, while learning Java shortly after being introduced to C++, Java seemed simpler and easier to learn and understand, hence more productive, as was said before. While program structure and syntax is very similar, there is no need to worry about pointers and other potentially dangerous language features.
This is really very broad and I think these are really 2 or 3 different questions. I'll address the first one very briefly. Java utilizes garbage collection, or autmatic memory management. That is, arguably, the biggest difference between it from a language like C++. There are clearly some potential for increase in productivity in that you don't have to worry as much about memory, although in reality you do need to pay attention to your references. Perhaps you could refine your question a bit.
Java works in browsers! (Milpa for example). You can say Flash too, but with Java you can leverage the numerous classes coming with it (another advantage over C++, even if both languages has a good set of free libraries on the Net) and your knowledge of the language.
As said, Java is supported on many platforms with minimal adjustments, with a fast, efficient VM, from big servers to mobile phones.
OO support is arguably better designed, avoiding mistakes done in C++. Somehow, C# is to Java what Java is to C++ ^_^ (I won't argue on this, I don't know C# enough actually, it is just an historical point).
In the same spirit, Java is slightly more abstract, avoiding pointers, manual memory management and some other low level stuff.
That doesn't mean than one is better than the other, STL helps C++ for some of the issues above, etc.
I am not sure how to answer the last sentence, these are object and method respectively, not classes.
I never used System.in yet, I suppose it is usable if you feed the Java program with < or | on the command line. And parseInt is a static method of Integer class.
The language features have already been mentioned (GC, reflection etc.). But there is another major difference: Libraries. I know there is the STL and Boost and all kinds of libraries out there, but they are not all of a piece, they all feel different. Often you are forced to use all kinds of C-APIs (e.g. threading or sockets, just to mention two things). All the C++ evangelists will now jump in and tell about some kind of cool OO-socket or OO-threading library, but they are not part of the STL. They should be. Its almost 2009 and everything is networked and multithreaded. This ought to be part of the standard library.
Why is it bad to use those C-APIs? Because it is hard to use them in an object oriented programm. Try using Win32's CreateThread() with the listener-pattern (C#-users: read "delegates").
For a "rich client application", where performance is not a big deal, I would always use Java or C#. If I need raw speed (think signal processing or embedded applications), I would rather use C instead of C++.
BTW: I have used all four languages (C, C++, Java, C#) for a long time.
If you like to program really the object oriented way, then you need to go from C++ to Java. One of the problems with C++ is that most programmers actually use it as C and don't exploit all its OO features. Java is here stricter.
With C++ you're programming "on the metal", whereas with Java you're programming towards a virtual machine. The Java software stack all the way down to the VM is constructed to give a highly abstracted programming experience. This is most clearly apparent in the use of datatypes "that just are" (i.e. the programmers need no understanding of how they translate into memory areas), garbage collection "that just works" (the programmers don't have to deal with allocation and deallocation issues) and the ubiquity of exceptions for error handling and propagation. Pointers are not part of Java, the system takes care of where and how things are allocated.
From this, you might see that the design philosophy of Java is very different from C++: Java tries to enforce that the programmer should stick to certain ways of working which are considered to be safe and to make programming easier. Some people hate this aspect of Java, other people love it.
It really depends on what you're trying to do.
For a lot of higher level functionality where optimal performance may not matter, Java is easier and more reliable to use. For example, garbage collection, array checking, etc. It's also sandboxed, of course.
For me, another major benefit of Java is the use of reflection and of run time class loading. I write a lot of plugins within pluggable architectures, and can ensure I can add more new classes to a running program on any platform. Last time I tried to do that in C++, I had to mess with DLLs and COM.