Oracle Announces JSRs for Java 7 and Java 8

Posted by Alex Blewitt on Nov 17, 2010

Sections

Development

Topics

JSR 335 ,

JSR 336 ,

JCP Standards ,

JCP ,

Java ,

Languages ,

Oracle ,

Apache Harmony ,

Programming ,

Companies ,

Apache

Share |

RELATED Research

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.

RelatedVendorContent

Introducing SQLFire: a memory-optimized, high performance SQL database

Tools to unit test your JavaScript

App Server Evolution: REST, Cloud, and DevOps Support in Resin 4

NOSQL for the Enterprise

Good Relationships: The Spring Data Neo4J Guide Book

Related Sponsor

VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface

1. Back to top

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

   by Fox Touche

   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)?

   Reply

2. Back to top

   This is good news

   by Jan Vissers

   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.

   Reply

3. Back to top

   JSR 308 Type annotations are available for a while now

   by Arul Dhesiaseelan

   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: types.cs.washington.edu/jsr308/

   Reply

4. Back to top

   Way too much focus on Java for my taste.

   by Jörg W Mittag

   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?

   Reply

5. Back to top

   PS: I just thought of some other things.

   by Jörg W Mittag

   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.

   Reply

6. Back to top

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

   by andrew mcveigh

   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?

   Reply

7. Back to top

   Too Slow

   by krishna srinivasan

   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.

   Reply

8. Back to top

   Oracle sucks

   by srikanth nair

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

   Reply