Oracle Announces JSRs for Java 7 and Java 8

Oracle has announced the umbrella JSRs for Java 7/8, covering a number of the features known from the earlier Plan B. The way JavaSE and JavaEE specifications are defined are by reference to other JSRs, rather than defining new content directly – but often will do so after those referenced JSRs are completed. In this case, many of the referenced JSRs are still works-in-progress, or in the case of modularity, not even known at this stage.

JSR 336, Java 7, has proposed to include:

• JSR 203, the New New I/O APIs for Java
• JSR 292, the introduction of invokedynamic to the JVM (though not method handles)
• JSR 334, also known as Project Coin, which is likely to contain
  • Strings in switch, to allow string literals to be used in switch statements
  • binary literals and underscores in numeric literals which will permit numbers to be written as 0b0100 and 1_234_5678 in source code
  • multi catch, which permits a single catch block to handle multiple exception types
  • diamond operator for generic creation, allowing the type of a generic assignment to be inferred from the generic type of the instantiation
  • try-with-resources, which provides a means to automatically close 'resources' (something which implements AutoCloseable, which will include IO streams)
  • varargs warnings, which will give warnings where varargs involving heap pollution may occur

However, this is just a proposal – the top of the JSR says “The final Java SE 7 Platform Specification might not include all of these JSRs, and it might include some JSRs not listed here.” It goes on to list some that might be included, as well as impacting the general JSRs for the JVM (JSR 294) and the Java language (JSR 901). It also lists some maintenance reviews and new features, such as the Nimbus look-and-feel and JDBC 4.1, which will support the AutoCloseable for database connections. As Alex Miller writes, My God, it's full of JSRs!

JSR 337, Java 8, has proposed:

• JSR 308, Annotations on Java Types, which permits annotations to exist in other locations (such as on generic arguments). Interestingly, this JSR appears inactive and hasn't been updated since 2007.
• JSR 310, the revised Date and Time API proposed by Stephen Colebourne
• JSR 335, or Lambda Expressions (they're not all closures!) for the Java language
• JSR TBD: Project Coin remnants, or what wasn't in Java 7
• JSR TBD: Java Platform Module system

What's more interesting about Java 8 is that some of these are not only still works in progress, but also not even proposed yet. Whether members feel they can vote on a JSR which depends on non-existent JSRs remains to be seen. Perhaps Oracle is trying to finesse Eclipse's view on the Java 8 thoughts by making it palatable to vote for, and then change the contents after the vote has been made. Interestingly, the recent moves with IBM may have caused Oracle to add the following with regards to modularity in Java 8:

In the case of the proposed Java Platform Module System JSR, it is understood that there is already a significant investment within the Java community in applications and frameworks built using the module layer of the OSGi Service Platform. The extent to which the Java Platform Module System should adopt, interoperate with, or otherwise accommodate OSGi will be a topic for that JSR's Expert Group and the Java SE 8 Expert Group to discuss and decide.

Not all of the analysis is positive. Stephen Colebourne looks in more detail at the licensing surrounding the TCK; the license for the TCK is here:

The definition of a "product" contains what looks like an unusual part (highlighted). It appears that a "product" must meet three criteria beyond the basic ones:

• "have a principal purpose which is substantially different from a stand-alone implementation of that specification"
• "represent a significant functional and value enhancement over any stand-alone implementation of that specification"
• "not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification"

I believe that Apache Harmony would fail all three of these tests (were the project to try and implement this JSR, which they probably won't). Since a "stand-alone implementation" would be OpenJDK/OracleJDK, the principal purpose of Harmony is clearly the same (not substantially different), Harmony does not offer significant functional enhancement, and Harmony would be marketed as a replacement for OpenJDK/OracleJDK.

He concludes with the observation that the Java system cannot be implemented by anyone other than Oracle:

To be honest, I'm surprised that the TCK license for Java SE 7 still contains any pretence that it can be implemented in open source by anyone other than Oracle. At least the restrictions are clear (and I suspect, but cannot prove, that very similar restrictions were offered for Java SE 5 in the Sun/Oracle vs Harmony dispute). The TCK license conflicts with the JSR! The JSR itself says:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This JSR defines a release of the Java SE platform targeted at embedded, desktop, server, and cloud environments. ([Stephen's] highlights)

So, the JSR is targetted at embedded environments! That's not what the TCK license says ;-)

At this point, Apache will probably make a symbolic “no” vote on the Java JSRs (though they will probably vote for Project Coin and Project Lambda as a nod to the technical contributions they will make to the language). However, it is unlikely that other JCP members will do the same, and at that point Apache will follow through on their threat to resign.