Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Oracle Announces JSRs for Java 7 and Java 8

Oracle Announces JSRs for Java 7 and Java 8

This item in japanese


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:

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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Re: JSR 292 - invokedynamic (though not method handles)

    by Fox Touche,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    JSR 292, the introduction of invokedynamic to the JVM (though not method handles)

    Does this mean that we can't dynamically invoke a method directly from Java code (without resorting to reflection and/or bytecode generation)?

  • This is good news

    by Jan Vissers,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There is again progress on the SE front, and the feedback from the devoxx (2010) conference is overall very positive. With IBM and Apple joining in the OpenJDK effort, it would be really great for the community at large to do the same and evolve the Java platform to the next level.

  • JSR 308 Type annotations are available for a while now

    by Arul Dhesiaseelan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You can use these tools today without waiting for JDK 8 and they are backward-compatible. Unfortunately this was pushed to JDK 8 when most of the work was already done. JDK 7 had some support, but in the last JDK 7 build (b118), they were completely removed as it was pushed to JDK 8. Most of the work is done here:

  • Way too much focus on Java for my taste.

    by Jörg W Mittag,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am one of the many developers who uses only the JVM and the JRE but not Java.

    I couldn't care less about lambda expressions in Java, because all of the half dozen or so languages I use already have lambda expressions, some of them for more than half a century. What I do care about are Function Types. But AFAICS, they aren't even on the roadmap for Java 8, let alone Java 7.

    Apart from invokedynamic, I don't really see anything interesting here for all the many non-Java JVM/JRE users. Where are the Tail Calls? Value Types? Function Types? Symbolic Freedom? Method Handles? When are we finally getting rid of Primitive Types and Covariant Arrays?

  • PS: I just thought of some other things.

    by Jörg W Mittag,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is a postscriptum, since I just thought of some other things that would be nice to have on the Java platform: support for Immutable Types and support for Pure Functions and Total Functions. Also nice to have: a standardized Meta-Object Protocol for interoperability between languages. And getting rid of the hardcoded type system in the JVM, either making the JVM untyped or replacing it with Pluggable Type Systems and a kind-of "Meta-Type Protocol", again for interoperability.

  • Re: Way too much focus on Java for my taste.

    by andrew mcveigh,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    When are we finally getting rid of ... Covariant Arrays?

    I can see why the other issues would cause concern for you, but why does the possibility of covariance in arrays restrict you? Is it because in a dynamic language you would detect the error on read rather than write/assignment?

  • Too Slow

    by krishna srinivasan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The Java 7.0 progress is very slow. I have been watching this development since few years back, still they are postponing the release dates. Also they have removed many of the good features. Hope it will be release beginning of 2011.

  • Oracle sucks

    by srikanth nair,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Do what oracle employee can able to do.... Dont try to pick mountain using fly...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p