Some thoughts on the Premium JVM and the benefits of freeing the JVM separate from Java SE.
Premium JVM
The JVM is a technology we sometimes forget to talk about, yet it is central to development on the Java platform. Like most other Java technologies, it has a JSR - #924
Clearly, all the other languages on the JVM - Fantom, Groovy, JRuby, Clojure, Scala ... - all rely on the JVM primarily. Each of them also rely on the Java libraries to some degree, but the JVM is their core, and many of them would like to only depend on the JVM in an ideal world.
At QCon San Francisco, it is reported that Adam Messinger announced in passing that there would be a premium version of the JVM alongside the gratis (free) version. This raises many questions:
- Will the premium and gratis version be released at the same time?
- Will gratis version still support the same range of operating systems?
- What extra features will the premium version have?
- Is this only management features?
- Or are there performance features?
- Who is the target market?
My concern is that once you have the split, there will be a product manager for the premium version. Their bottom line and job success will depend on moving people from gratis to paid. They will therefore lobby against adding to the gratis version and rachet up the cost of the paid version.
Logically, this is just an extension of the JRockit product and shouldn't be a threat. Lets hope that the answers to the above are suitable and provided soon so the community has reassurance.
Update 8th Nov: This Oracle press release from September 2010 indicates the underlying situation - that "premium" simply refers to a continuation of the JRockit paid for elements. I still hope that more detailed information can be provided.
Oracle is currently working to merge the Oracle Java HotSpot Java Virtual Machine (JVM) and the Oracle JRockit JVM into a converged offering that leverages the best features of each of these market-leading implementations. Oracle plans to contribute the results of the combined Oracle Java HotSpot and Oracle JRockit JVMs to the OpenJDK project. The Oracle JDK and Java Runtime Environment (JRE) will continue to be available as free downloads, with no changes to the existing licensing models. Premium offerings such as JRockit Mission Control, JRockit Real Time, Java for Business and Enterprise Support will continue to be made available for an additional charge.
Update 10th Nov: This further update from Oracle provides a public HTML summary of what was announced at JavaOne. I understand this should be considered to be the definitive word on the strategy, and effectively confirms that the "premium JVM" name is just the continuation of those parts of JRockit that were already paid for.
Open JVM
Since the recent news that Oracle will not allow Apache Harmony to complete as an implementation of Java SE, I've noticed a number of tweets and blogs questioning the whole JVM platform, not just Java.
There are now people considering moving to the .NET CLR or other platforms away from the JVM. This cannot be a good thing for Oracle!
As Oracle have stated, the community cannot have an open standard for the Java SE platform. If we accept that (and given the history and legalities we shouldn't) then what is the next best thing?
What if there was an open standard for the JVM?
The JSR exists - 924. All Oracle needs to do is allow it to be freely implemented, without Field Of Use or any other limitation, and independently of the rest of Java SE (which I don't believe is possible at the moment).
Update: I asked for clarification from Henrik Stahl of Oracle. He replied to me by email giving me permission to reproduce this here:
Stephen, You asked me if it was possible to implement a JVM without Java. I looked into it and there seems to be technical showstoppers. The JVM specification was clearly written with Java in mind. There are dependencies in the spec on java.* classes such as Object, ClassLoader and various exceptions. A JVM cannot be implemented according to the spec without these classes. So it's not possible for you to implement a JVM without *some* Java. And if you have *some* Java you probably have to implement *all* of Java, since subsets are discouraged due to fragmentation concerns. (Disclaimer: I'm no lawyer. This is my personal interpretation, and is not an official Oracle position.)"
I don't see this as threatening to Oracle in the same way as Java SE is (at least not threatening technically - politically its always hard to tell). The JVM is a simple input/output machine, theoretically easy to test for compatibility independent of the rest of Java SE (please contradict me in the comments if you have additional knowledge here).
Making this available has huge benefits: It is a good PR move, softening the tension in the Java community. It allows part of Apache Harmony to be released properly. It ensures true competition in JVM performance and additional features in the same way as Java EE has benefitted. It also removes any lingering concerns that the gratis/premium version of the JVM could be abused.
I've always thought that Sun missed a huge trick in not getting the JVM adopted as the heart of language programming in all browsers. Technically, Javascript could run on top of the JVM embedded within the browser. Sounds odd? Well not if the JVM were a freely implementable specification without restriction, capable of being extended, tweaked and integrated in different ways.
For example, a JVM could be written that is more modular, or slimline more suitable for different environments, such as one designed explicitly for a world where Javascript was the primary language it ran. Or a JVM could be implemented directly on top of the CLR or LLVM, or integrated within. Or a JVM could even implemented in another language like Ruby or Javascript rather than C (I remember seeing this once, so its technically possible!).
There is a huge set of opportunities here!
And for Oracle, that would mean embedding the JVM bytecode definition at the heart of many more areas. Which would reconfirm the JVM as the core technology today.
Hey, if browser vendors adopted it, we could write real code in the browser instead of pesky Javascript! Which would surely be a better technical solution than cross compiling JavaFX down to Javascript.
Summary
The premium JVM concept should just be JRockit continued. But, given recent actions by Oracle, there has to be concern that its the first move to charging for the "real" JVM. Clarification is needed. Update: see above
One way to turn the situation around would be to make the JVM freely implementable separate from Java SE. Apache Harmony would benefit, lessing tensions, but so would many other environments. A JVM implemented using the CLR or LLVM would be immensely useful. And maybe, just maybe, we could get to write real code in browsers on a multi-platform VM instead of Javascript.
Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK
Hi Stephen -
ReplyDeletecan you please clarify your intent? There are already many JVM implementations, and they compete in different markets. Look at Wikipedia "List of Java virtual machines". What more do you want or need?
Regards,
Patrick
Of all the VM's, the JVM is the one that comes last to my mind when talking about embedding a real VM in browsers. Partly due to it's heavyweight and partly due to how tight it's controlled by Sun/Oracle.
ReplyDeleteGnome/Mono hacker Miguel de Icaza blogged about a similar idea regarding the CLR: http://tirania.org/blog/archive/2010/May-03.html
the problem is that one of the main strengths of building other languages into the jvm was the existing body of libraries, both built-in and independent. Since not having the built-in libs means all libs won't work (they build upon each other), the jvm right now would be near useless until a new lib stack was created. Might as well start using GoLang...
ReplyDeleteBTW comment authentication failed??
Patrick, that i believe , there are several good JVM outside, and i believe oracle try to claim all of them is his product.
ReplyDeleteor u get sue :)..
that is worst ..
> "The JVM is a simple input/output machine, theoretically easy to test for compatibility independent of the rest of Java"
ReplyDeleteSome libraries are quite closely tied to the JVM. Math, Concurrency, and java.nio.*Buffer, for example. Meeting the Math specifications might present a significant challenge to developing an efficient implementation on top of CLR (for example).
Patrick, Frans, I'm trying to get clarification om whether the JVM is or isn't implementable in open source without restriction. Its unclear to me right now as to whether the open source JVMs listed are authorised to claim that they are JVMs.
ReplyDeleteMark, I suspected there might be some connection to the class libraries but didn't expect that much. Do you know of any documentation describing the connections?
Stephen,
ReplyDeleteplease continue your quest for clarification! Many people want to know. Me, I wonder if restrictions on the JVM might hamper the future of Scala. AFAIK Scala only needs a JRE, but in which way will it remain free and perform well in the future?
> recent news that Oracle will not allow Apache Harmony to complete
ReplyDeleteDo you have a link for that?
@Stephen
ReplyDeleteYou wrote:
""
I've always thought that Sun missed a huge trick in not getting the JVM adopted as the heart of language programming in all browsers. Technically, Javascript could run on top of the JVM embedded within the browser. Sounds odd? Well not if the JVM were a freely implementable specification without restriction, capable of being extended, tweaked and integrated in different ways.
""
I definitely agree with you.
Indeed, I wrote many times about the (lost) opportunities of SUN.
See for example:
(1) A false piece of news may become real as Java and JS move closer
"During the early days, JavaScript was sometimes advertised as a scripting language for Java; a kind of Java cousin. Well, it's still not that true, but without doubts, Java and JS are going to more and more close. "
http://www.jroller.com/dmdevito/entry/a_false_piece_of_news
Then, it could possible to run JavaScript on top of a JVM.
That's why I have written:
(2) HotJava may come back, due to existing, or coming, components, like JWebPane
http://www.jroller.com/dmdevito/entry/hotjava_may_come_back_due
But the opposite is also possible, because, as stated above, Java and JS are quite close
(3) Why not running a Java Browser Edition on top of Firefox VM (Tamarin) ?
http://www.jroller.com/dmdevito/entry/why_not_running_a_java
Note that, so far, Google has bypassed the lack of a Java Browser Edition
Indeed, (4) Google has released a (kind of) Java Browser Edition with GWT
http://www.jroller.com/dmdevito/entry/google_has_released_a_kind
During a chess play, the JVM would be the Queen (because it's so important), while the King would be the compiler, and all other chess pieces would be the Java library. So, indeed, due to SUN's gameplay, this Queen has not met all its possible opportunities, and due to its power, it's still a serious topic to have a free-enough JVM...
PS : unfortunately, I could also add here the missing opportunities from JWebPane that would have been quite a good move for "merging" HTML/web+Java capabilities in order to push higher and higher the Java platform:
(5) About Swing future and JWebPane relationships
http://www.jroller.com/dmdevito/entry/about_swing_future_and_jwebpane
> "Hey, if browser vendors adopted it, we could write real code in the browser instead of pesky Javascript!"
ReplyDeleteJavaScript is real code and is a real programming language. I'm far happier coding my webapps using REST with JavaScript in the browser rather than struggling with JSF.
Andy, the Oracle turning Harmony doen link is https://blogs.apache.org/foundation/entry/statement_by_the_asf_board (nothing 'official' from Oracle/JCP until the meeting minutes are published.
ReplyDeleteStephen,
ReplyDeleteTo be fair, refusing to remove the FOU restriction from the TCK is one thing. "Not allowing Harmony to complete" is quite another. Not being willing to live with the FOU restriction is Apache's choice. And giving up on Harmony because they then can't use the TCK is also Apache's choice.
I wonder, is it allowed to re-implement substantial part of JavaSE standard library as a native library (eg C++ library), ie. reusing only the class and method names. Without calling it Java library.
ReplyDelete