JDK 7 delayed again... how bad is that?
Mark Reinhold announced today that the JDK 7 / JavaSE 7 project has slipped once again: mid-2011 without Jigsaws and Lambdas, late 2012 for JavaSE 8 with those. The delay (or some other bad news like dropping features) was already expected by anyone who tracks the project. But really, how big and bad is this delay?
As a big enthusiast of both Jigsaw and Lambdas - and as a tech writer who just published two massive articles on Java 7 & JavaSE 7 (in the Brazilian Java Magazine) - I was initially... very unsatisfied, to be polite. But doing a reality check, the slip is neither as big, nor as bad as it seems at first sight.
The reason of course, is JDK 6. I have continuously tracking the "post-6uN" releases, where Sun/Oracle continues to push the envelope, delivering as much improvements as they can without breaking their own TCK. See my recent coverage of 6u21 for example. I'm already testing the first build of 6u23, that (besides a bunch of Swing fixes) carries another massive VM update, now to the bleeding-edge HotSpot 19 (the very latest one from JDK 7 at the moment). This includes such high-profile JDK 7 features as the latest G1 collector, the complete VM support for JSR-292, and other items like CompressedOops with 64 Gb heaps, CMS fixes and tons of smaller VM/runtime fixes and improvements.
Version numbers are a somewhat arbitrary thing. Sun changed the
J2SEJavaSE versioning schema a few times, always to the dislike of half the planet. Some people think that 6u10 should have been called 6.1. In this case, I'd rebrand 6u14->6.2, 6u18->6.3, 6u21->6.4 and 6u23->6.5. Maybe we would feel better: "Yeah JDK 7 delayed, that sucks... but at least we're getting 6.5!"
The restriction of no changes in the language syntax or public APIs puts some limits on the features that can be delivered with the (so-called) maintenance updates. But these restrictions are not impossible to circumvent; they are just cumbersome. For example, you may wonder how good is having the VM back-end for JSR-292, if the front-end (the java.dyn APIs, some bits of syntax sugar) cannot be available. It will probably be good enough for the projects that need this the most: dynamic languages that target the JVM, such as JRuby, Groovy and Jython. I suppose that a future update of the JSR-292 backport will be able to make use of the new back-end, perhaps by adding an extension jar with the missing APIs to the bootclasspath. Even the new invokedynamic bytecode, that needs a new classfile version, may not be a big problem: the backport solution might use tricks with "magic" internal APIs that the VM would replace to emit a dynamic invoke; or the VM launcher could have some -XX:+InvokeDynamic option. Both carrying all necessary disclaimers as unsupported, VM-specific extensions. Nothing new here, the JDK already contains literally hundreds of private, magic APIs and options. And the argument of "only runs on Oracle JDK" is much less important than before... which brings my next subject: OpenJDK.
Who cares if something works "only" in the Oracle JDK? Any such feature will also work on OpenJDK, that is free software and (thanks to community projects like IcedTea, Zero and Shark) runs on even more platforms than the official Oracle JDK. (The entire OpenJDK project was a great move by Sun as it basically subsumed the older Free Java projects - these days, nobody cares to test Java apps on Classpath or GCJ.) I suspect that this thinking will do a lot to promote the Oracle/Open JDKs as an even stronger de-facto standard than before. Another important JavaSE implementation, the JRockit VM, is owned by the same company, and will eventually be merged with HotSpot. So in the end there are only two relevant JDKs: Oracle's and IBM's. All other production-quality JDKs, such as Apple's or HP's, are mostly ports of Oracle's code, so they tend to follow its steps including most extensions. The notable exception is the Excelsior JET static compiler, but they have a smaller market share, and their business depends on having the best possible compatibility with the standard (read: Oracle) JDK.
Additionally, features like JSR-292 are not really vendor-specific extensions. They are just standard features... from the next platform release. I don't see a reason why IBM wouldn't want to make a similar move, and backport their own JSR-292 support from the ongoing IBM JDK 7 project to some update of IBM JDK 6. (Just keep the feature disabled by default, so ultra-conservative WebSphere admins won't freak out.) Last time I checked IBM was making some noise in dynamic languages support, so that would even be a business necessity. Maybe a future release of projects like JRuby would need different extension jars and launch scripts for Oracle/Open JDK and IBM JDK, and that would be all.
Programmers love new syntax and new APIs, and it's much neater when these are included in the core platform: less stuff to install, less worries about support, toolchain or portability. But truth be said, these conveniences are not deal-breakers. New APIs have been traditionally available from multiple sources, from open source projects to the "upper" JavaEE specs; and an increasing number of Java (Platform) programmers are now comfortable with alternative languages and compilers, from Scala and Clojure to Oracle's own JavaFX Script.
My last comment for Oracle: Please include the Tiered Compiler in 6u23, and I will definitely be completely fine with the slip of JDK 7. Quality first, it's done when it's ready, and all that. ;-)