In a post entitled Re-thinking JDK7 (and cross-posted to jdk7-dev), Mark Reinhold put forward a suggestion that certain previously planned elements of JDK7 be suspended until JDK8 in order to get the release out of the door sooner rather than later. The suggestion has caused variety of discussions as to whether this is a good or bad idea.
Having accepted that delays to the JDK have caused the previously announced timetable to slip (which it was never likely to make anyway), the current discussion now centers on whether to ship a version earlier with what is currently supported, or wait until everything is ready. Mark suggests that:
Our current estimate for this “Plan B” is that we could ship a reduced JDK 7 in mid-2011 and JDK 8 in the second half of 2012.
To summarize:
- Plan A: JDK 7 (as currently defined) Mid 2012
- Plan B: JDK 7 (minus Lambda, Jigsaw, and part of Coin) Mid 2011
- Plan B: JDK 8 (Lambda, Jigsaw, the rest of Coin, ++) Late 2012
Ironically, Mark's blog is subtitled “There's not a moment to lose!” but as several comments to the post say, it's better to ship early and ship often than to not ship at all. And although there are some much-desired (and some less desired) features in the Plan B feature set, there's no doubt that the Plan B part of Project Coin will be beneficial to the Java language. These were clarified by Joseph D. Darcy as including:
- binary literals and underscores in literals
- strings in switch
- diamond operator
- improved exception handling
- simplified varargs method invocation
try-with-resources
Plan B will also include the jsr166y classes (ForkJoin, TransferQueue, Phaser). In addition other improvements to the JVM, including JSR292 (support for invokedynamic) will be present at a JVM level. Although this may seem to have little use for the statically typed language Java, it can be used for optimisations where Method.invoke() is currently used (for example, in RMI or other enterprise server applications). If this also includes language support for MethodHandle literals as well, it will be much easier to use methods inside a Java class instead of having to use reflection to find the appropriately named message. (MethodHandle literals use the invokedynamic under the covers but require a change to the JLS; so it's possible that the Plan B will include the invokedynamic VM instruction and MethodHandle class, but not the literal support.)
Those implementing alternative languages on top of the JVM are excited with the proposed timetable change, since it will bring invokedynamic to a usable state faster than if it were delayed until 2012. (In any case, note that both plans put Lambdas et al arriving no earlier than 2012.) Charles Nutter, who is working on both JRuby and Mirah on top of the JVM, is stoic about the changes:
Method handles are perhaps the most important change coming in JDK7 for the work I do. They are sure to become a key part of *all* JVM languages that want to be able to represent functions or function pointers without the associated overhead of generating single-method classes (as basically *all* the current JVM languages are forced to do in one place or another). But the long delay in making them available has meant language implementations like JRuby have had to keep plodding through the mud, building ever-cuter code generation strategies to avoid blowing up permgen (or just to avoid eating too much memory). The sooner we can get them into a product release the better.
So would I be willing to give up Jigsaw, Lambda, and Coin? Jigsaw and Coin, perhaps, though they'd certainly be missed. As for Lambda...if it can't be done "right" in a short term, with a real function type and integration with method handles and invokedynamic, it should be delayed until it can be done right. It pains me to say so, but we do have other languages on the JVM that can do closures now, including my own JRuby and Mirah (which, incidentally, provides closures and more without *any* runtime library or JVM support), and for us JVM "systems programmers", anonymous inner classes are still "pretty good" (check out the JRuby codebase...we use hundreds of them).
Oh, and for folks crowing about Scala...please explain to me how Scala solves any of the missing features that "Plan B" would omit. Yes, it has closures, but they're generally not interoperable with other languages or regular Java code (unless you limit your design considerably), which makes them useless for all but Scala developers. There's nothing to address the goals of Jigsaw. And most of the bits of Coin that Scala provides are (I believe) already ready to go. Scala is not a substitute for Java as the lingua franca of the JVM, and it never will be.
Others think that release early, release often could be done even more frequently. Even though Java 6 has been with us for a while, the versioning scheme hides some important changes that the VM has undergone in the timeframe. Osvaldo Pinali Doederlein writes:
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. 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 other advantage of a delay is that it enables things to be done right, rather than done in a rushed form. There were competing goals in the Lambda project and the core Java libraries (for example: how to retro-fit the Collections classes in a short period of time to take advantage of lambdas) which would have likely caused problems in the short term. By buying more time for the Lambda project, these may be harmonised in time for JDK8 without holding up JDK7. Not only that, but the latest proposal completely eliminated function types in Java (previously covered on InfoQ). There has been a call to revisit the decision in the light of more time being available. However, since it was not clear why they were removed in the first place (problems with the type system or lack of time), it is not clear whether they will come back again.
The same could also be said of Jigsaw, JDK's attempt at a module system. Whilst OSGi has long been the standard for module systems in Java, Jigsaw attempted to re-invent the wheel as a way of partitioning the Java language libraries. Qwylt exists as a way of trying to unify those two, but as has been noted elsewhere, the JVM and the Java libraries really serve two different purposes and a Plan C to separate the JVM from the Java Libraries would be of great advantage to all. That way, libraries (like the IO, NIO, NNIO, NNNIO) could evolve at their own speed rather than being dependent on any one particular release of the JVM+Libraries combination.
Peter Kriens writes:
Java is slowly being broken by the misconception that the bigger the Java platform the better it becomes. However, bigger means more internal dependencies and these dependencies tend to increase the complexity of a platform quickly. The more rope you have, the more tangled it can get. Repeatedly slipping schedules are one of the symptoms.
Modularity is the only mechanism that allows us to have our cake and eat it too. If Java consisted of a core Java platform we could easily include the JSR implementations as separate modules. I never use Swing , so why does my platform have it? And maybe I need it in another version if I use it. Modularizing the JSRs would maybe complicate the life of trivial applications but for any real application handling external dependencies is already part of their complicated life. Complicated because surprisingly Java provides no support whatsoever for handling these dependencies.
What we need is a core platform that is minimal but understands true modularity. Instead of including all these javax packages, this minimal Java should only include well defined core packages and also a mechanism to properly handle modules from (remote) repositories that make it trivial to add libraries and applications to my desktop machine and servers. Perl can do it, Ruby can do it, Python can do it, why does Java have such a hard time doing the same thing? Or live up to its promise and do it better?
We do have the technology, all the parts are there. Please Oracle, this delay provides an opportunity, can we make Java agile again?
With the short announcement that Oracle are considering delaying some previously planned features of JDK7, they have turned a problem into a PR coup. The volume of comments encouraging the “release early, release often” approach gives them weight to announce the delay formally at JavaOne and claim that the community is behind them. (Had they announced it solely on the Lambda-Dev list, they would have got a much bigger proportion of negative responses and less of the positive responses.) It also lends hope that the Java platform will have time to mature libraries that are not quite ready (lambda) and consider whether they are necessary (jigsaw). One thing's for sure; by bringing the problem out into the open, Oracle has finally understood the value of community opinion.