Pure Danger Tech


“My God, It’s Full of JSRs!”

17 Nov 2010

That’s right, with apologies to 2001 (and a tip o’ the hat to Scott Bale for the title), we finally have a JSR proposal for Java 7 (JSR 336), and egads one for Java 8 (JSR 337) to boot.

This seems like an opportune moment for me to reminisce briefly about ye olde Java 7. Back in January of 2007 JDK 6 was fresh out of the gate and in an idle moment I did some poking around for clues about what might be in store for the next version. Surprisingly I found clues but no coherent source for information. I started piecing scraps together on my Java 7 page and doing a weekly roundup of news and links. Even back then, the BGGA proposal for closures was out, modularity JSRs existed, and while there were lots of ideas it seemed hopeful that an umbrella JSR would coalesce out of the noise in short order. I eventually abandoned the weekly roundups and started my Java 7 link blog, which I still maintain at a reduced frequency.

In the meantime, there have been numerous spec lead changes, the ongoing Apache Harmony TCK kerfuffle, the Sun acquisition by Oracle, 4 JavaOnes, and more closure/lambda proposals than I can count. So, here we are at long last.

The proposed contents for inclusion in Java SE 7 include:

The latest JSR 166y update is not included in the list above or in any of the other new JSRs, but I have no fear that the expected updates will be included as well.

All in all, I think having a JSR that includes the new filesystem API and the syntax sugar in the language changes will be good to have out there. In particular, I expect the diamond syntax, ARM blocks, and exception improvements to clean up some of cruft in common Java code today. And the JSR 292 invokedynamic changes are crucial to support the growing ecosystems of the leading JVM languages (like Groovy, Scala, Clojure, and JRuby). There are also a ton of improvements that have been bleeding into the OpenJDK 6 impl for years now, including major stuff like the G1 garbage collector, the quickstart improvements, etc.

The Java SE 8 JSR is necessarily a bit more sketchy but contains:

  • JSR 308: Annotations on Java Types
  • JSR 310: Date and Time API
  • JSR TBD: More Small Enhancements to the Java Programming Language (OpenJDK Project Coin)
  • JSR 335: Lambda Expressions for the Java Programming Language (OpenJDK Project Lambda)
  • JSR TBD: Java Platform Module System – the JSR formerly known as JSR 291, JSR 277, and Project Jigsaw

And the following list of JSRs are called out as NOT part of Java 7 and are also NOT included in the Java 8 JSR so are presumably less likely to make it in Java 8 or maybe ever:

  • JSR 260: Javadoc Tag Technology Update – this has been pushed through at least 2, maybe 3 or 4 SE versions now, so no big surprise here. Custom doclets have allowed people to get what they need here anyways.
  • JSR 295: Beans Binding – originally part of JDK 7, 295 has been pushed out and may resurface in Java EE or SE in the future.
  • JSR 296: Swing Application Framework – 296 was hot early on but suffered personnel changes and never really re-gained any momentum. I think all the momentum in JavaFX overshadowed any interest in 296.
  • JSR 305: Annotations for Software Defect Detection – this is indirectly related to JSR 308 and doesn’t really need to be part of the JDK to be useful (it would just help standardize the annotations). It exists now and I suspect it will be around regardless of JDK inclusion.

Stephen Colebourne does his usual tasty analysis of the legal and political issues around licensing. I have the same expectations as him – these JSRs will be approved by the executive committee and per their ultimatum, I expect Apache to withdraw from the JCP. With the announcements from IBM and Apple re OpenJDK, it appears that Oracle has forged a path through this issue for better or worse and likely unstuck the JCP. This is very sad but I suspect the world will get on regardless.

I don’t expect Harmony to be getting much love from anyone but Google soon. It will be very interesting to see where the Google / Oracle lawsuit goes. Perhaps it will result in an OpenJDK deal with some money on the table (presumably Oracle is seeking financial benefits in the mobile market) or the schism could deepen and Google could take a deeper stake in Harmony as a custom implementation for Android.

The proposed schedule has a final release for Java SE 7 in July 2011 and for Java SE 8 in October 2012. I actually believe that Oracle will follow this release schedule. They’re making a public commitment here and while they may need to de-scope a bit to make it, I’m sure they will. Having a reliable schedule and plan will be a refreshing change even if we don’t like every decision.