Oracle Blog

Official and not-so-official thoughts on Java

Thursday Aug 11, 2011

Updated 8/18 Please use a real email when commenting; some of your questions are not of general interest and will not be posted but I can often respond privately.

This blog entry will be used to host commonly asked questions related to Java 7. I have pre-seeded it with a few that have come up
since the July 28 release. If you have additional questions, feel free to post as a comment to the blog. I will not respond to them
in the comments, but will instead aggregate and update the blog entry. Only questions of general interest to the community will be
answered here. Fire away!

Q: When will JRockit be available for Java 7?
A: It won't. As we explained last year we are merging JRockit and HotSpot into one single JVM. JDK 7 contains the first
release of this converged JVM, where one of the first steps was to start removing the PermGen concept. Future JDK 7 updates will complete the PermGen removal, as well as add more visible features from JRockit.

Added 8/18
Q: I have created an application in Java 7, but when my users try to run it they get an Unsupported major.minor version 51.0 error. What does this mean and what can I do about it?
A: If you compile an application using javac in Java 7, the resulting classfiles will have the 51.0 version number. Versions of Java prior to 7 do not recogize this number, so your users will have to upgrade to Java 7 prior to running your application. If you are not using any Java 7 APIs you can try to compile your application using javac -target 1.6 to create a 1.6-compatible classfile. If your application is deployed using webstart you can specify the minimum version required. For more information, see the docs on Java Web Start and JNLP here. This issue will go away once we trigger autoupdate to Java 7 for end-users currently having Java 6 on their desktops. The timeline for this is not yet determined, we want to give developers time to work out any issues between their code and JDK 7 first.

Added 8/17
Q: Will the converged JVM get the feature that allows JRockit to allocate more heap on Windows?
A: For reference, the feature you are asking about is described here. Adding this to HotSpot turns out to be quite complex due to how the JVM is architected. Our current plans for convergence do not include this feature. We recommend using a 64-bit JVM instead, which does not run into this Windows limitation.

Q: Where can I find the source code?
A: The source code for the Java SE 7 Reference Implementation is
available from the JDK
7 Project in the OpenJDK
Community.

Added 8/17
Q: What is the difference between the source code found in the OpenJDK repository, and the code you use to build the Oracle JDK?
A: It is very close - our build process for Oracle JDK releases builds on OpenJDK 7 by adding just a couple of pieces, like the deployment code, which includes Oracle's implementation of the Java Plugin and Java WebStart, as well as some closed source third party components like a graphics rasterizer, some open source third party components, like Rhino, and a few bits and pieces here and there, like additional documentation or third party fonts. Moving forward,
our intent is to open source all pieces of the Oracle JDK except those that we consider commercial features such as JRockit Mission Control (not yet available in Oracle JDK), and replace encumbered third party components with open source alternatives to achieve closer parity between the code bases.

Added 8/18
Q: How much more in JDK 7 is open source compared to JDK 6?
A: All new JDK 7 features are open source, as is the Java SE 7 Reference Implementation. Also, the majority of the features that are ported from JRockit are open source (or will be once they are in the JDK 7 code base).

Updated 8/17
Q: Why isn't Java 7 available on java.com yet?
A: The site java.com is used for end-user downloads. As with previous major versions of Java, JDK 7 is first made available
to developers so that they can ensure that their Java programs work with the new JRE version before it gets rolled out to millions
of end-users. There is a unobtrusive link from the website that takes you to developer downloads on java.oracle.com.

Q: Where can I find API documentation?
A: Javadocs are available here.

Q: What is the status of the port of Java 7 to the Mac?
A: Feature development is still going on in the OpenJDK Mac OS X Port 7 Project. You can see the detailed status here.
Once that Project has made sufficient progress - say a couple of months
from now or so - we plan to build and make a developer preview
available from the main JDK download site. We will then work with Apple
and others in the Mac OS X Port Project to finalize remaining feature
work such as installers and plugin/webstart, and then go through the
usual steps of one or more beta releases and/or release candidates
before we get to GA. If you are anxious to get started, there are a
number of third parties that provide binary builds from the OpenJDK
code. Just use your favorite search engine and you'll find
several.

Q: I have read about issues with Apache Lucene running on JDK 7, what is that about?
A: The Lucene project has reported that running Lucene triggers a JIT bug that causes a JVM crash. It can be worked around
by disabling the broken optimizations with command line options, see the bug reports for details.
The three bugs that Lucene reported have been fixed in the OpenJDK code, in addition to a fourth bug impacting Lucene that Oracle
found (7070134,
7068051,
7044738,
7077439), and are included in current builds
of JDK 7 Update 1 (and will remain included unless the fixes cause regressions). For more information on how
Oracle prioritizes and works with external bug reports see this blog by Dalibor Topic. And while I'm at it -
many thanks to all those of you who have tested JDK 7 and reported issues!

Q: I read the JDK 7 license. It mentions something about Commercial Features, what does that mean?
A: Sun versioned the end user license together with the binary, which made it clear what terms applied for a particular release. However, it also meant that a Java user would have to re-review the license for every new release (including update release), which lead to uncertainty around future licensing conditions. Oracle's approach is to minimize the number of licenses used for Java - ideally getting it down to only one. This means a more predictable and stable licensing situation, at the cost of a slightly more complex license text since it needs to be able to cover more scenarios. When we made JRockit free we modified the Binary Code License to make it
cover all versions of Java, as well as JRockit. This was announced in one of my previous blog posts.
The "Commercial Features" clause is there to allow us to port over value-add features from JRockit to the converged Hotspot/JRockit JVM starting with JDK 7.
Full details on what features are non-free can be found in the product
documentation. In the standard JDK 7 GA binaries, there are no commercial features so there is no risk that you use them by mistake. As we move
such features to JDK 7 in a future update, our plan is to require an explicit flag to enable them. Note
that these features are only restricted "for any commercial or production purpose" so individual developers need not worry. For full information, read the
license text itself.

Thursday Jul 28, 2011

We are very happy to announce that JDK 7 is now GA.
The release is on time according to the announcement we made at JavaOne last year
and with no significant changes to release content. I would like to express a heartfelt thank you to all those at Oracle and elsewhere in the community
that has helped with this release (honorable mentions).

Wednesday Jun 08, 2011

Update 7/22/2011: The JavaSE 7 Reference Implementation is now available for download from java.net.

We are now less than two months away from the JDK 7 release date. In parallel with the development project, Oracle and the other members of the Java SE 7 Expert Group have been putting the finishing touches to the Java SE 7 specification (JSR 336). In its role as the specification lead, Oracle is responsible for delivering the Java SE 7 Reference Implementation. In line with our strategy towards a more open Java ecosystem, we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license.

The role of the Reference Implementation (RI) is to be used as the gold standard for all Java implementations. In order to have an implementation certified as Java SE compatible, an implementor must pass a large number of compatibility tests - the Technology Compatibility Kit (TCK). Furthermore, implementations may be compared to the RI as an additional check of compatibility. Basically, if your implementation has been certified to have the same behavior as the RI then it is Java compatible. For more information on this topic, consult the JCP FAQ.

Historically, Sun always used the Sun JDK as the RI and made it available under the Binary Code License (BCL). This was very convenient for Sun since it meant that its product implementation was compatible by definition. However, it was also confusing since the Sun JDK contained quite a few features that were not part of the standard, such as the Java Plugin. Also, continuing this practice would make things difficult for open source implementors as they would not be able to study and evaluate the official RI source code. (The source code for the Oracle JDK is slightly different from OpenJDK - something we will be addressing moving forward).

With that in mind, Oracle will:

Create RI binaries based only on the OpenJDK code base.

Make RI binaries available under the BCL (the normal Java license)
for commercial implementors and GPLv2 (with the Classpath exception)
for open-source implementors.

Continue to provide the TCK to commercial licensees, but also update
the OCTLA
license so that it covers Java SE 7. The latter allows open source implementators
gratis access to the TCK to verify their implementations.

We believe that these changes will lead to improved clarity in the Java community, as well as make things easier for both commercial and open source Java SE implementors.

Update: I have been asked to make a couple of clarifications. First, there is no change to our policy vs Apache Harmony. OCTLA is a program that allows free access to the TCK for OpenJDK-derived implementations licensed under GPL and is only intended for that purpose. Second, the Oracle implementation (what you find on java.com or java.oracle.com) will remain under the BCL license only. Finally, to be completely clear, the OpenJDK source code remains under GPL.

Tuesday May 17, 2011

As previously communicated our strategy is to converge the HotSpot and JRockit JVMs into a single best-of-breed JVM
(blog, press release). While most of the work involved in this effort is engineering - taking ideas and features from JRockit and
porting them over to OpenJDK - we have also been working on convergence from a licensing perspective. This work is now complete,
and we have changed the license that we distribute both the Oracle (Sun) JDK and JRockit under. The new license is a slightly
modified version of the Binary Code License that Sun has used for various Java downloads for many years. The full text of the new
license is available here. For comparison, the old BCL is available here.

Summary (check the license for details):

JRockit is now free (gratis) for development and internal production use on general purpose computers. Clarification: I stole this wording from the license text. These are the same terms that have been used for the Sun JDK for the last ten years or so.

Commercial features continue to require a commercial license. This includes most features currently in JRockit Mission Control, JRockit Real Time and JRockit Virtual Edition. Previously, it was only possible to get a commercial license for these features as part of Oracle products (such as WebLogic Server), they can now be purchased standalone for use with any Java application.

No other major changes. Specifically, redistribution of the JDK is permitted, now also applicable to JRockit.

Q: Does this mean I can now use JRockit with any Java application?
A: Yes, under the same terms as you currently use the Oracle (Sun) JDK. You don't need to inform us and you don't need to pay anything.

Q: You're making me very curious about JRockit, how can I find out more?
A: I highly recommend the JRockit book (Packt, Amazon), which is very detailed and a good read. It will also give you
a good picture on what will be ported into OpenJDK as we continue to move forward.

Q: Why are you making JRockit free?
A: Since we are converging the JVMs technically it makes sense to treat them as a single "product" with two different
incarnations/implementations. Second, by making JRockit free we hope to get more feedback on any regressions in the converged JVM vs current JRockit, which will help our convergence project.

Q: Are you planning on making JRockit open source?
A: The converged JVM will be made available through OpenJDK. We will not open-source the current JRockit implementation.

Q: How do I find out more about the updated commercial offerings?
A: We will have more information about that later, though you can contact sales if it's urgent. Our first priority was to converge the license
terms.

Q: How do I find out which features are free, and which are commercial?
A: See the docs for details.

Q: Are any features that were previously free now for-charge?
A: No. It is very important for us that Java remains easily accessible to everyone, and that means free (Oracle JDK) and open (OpenJDK).

Q: How do I purchase commercial support?
A: We have been working on an updated version of the Sun Java for Business program, which will cover both the Oracle (Sun) JDK and JRockit.
More detail on this will be available soon. Again, if you have urgent questions, contact Oracle sales.

Q: How does this license change affect OpenJDK?
A: Not at all. OpenJDK is released under an open source licensing model.

Q: I am currently using the Oracle (Sun) JDK? Should I switch to JRockit?
A: If you move from Hotspot to JRockit now, you will have to plan a move to the converged JVM later. Whether it's worth it depends on your rationale for considering a move. Overall, we believe most of you probably benefit more from looking at JDK 7 instead, but it depends on what your needs are.

Q: Do you have any information on the differences between the JVMs?
A: There is some information in the docs but it's unfortunately somewhat old and a bit limited.