JDK7 Feature Slip

| by Alex Blewitt Follow 4 Followers on Sep 10, 2010. Estimated reading time: 8 minutes |

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:

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.

Rate this Article

Adoption Stage

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.

Tell us what you think

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

Email me replies to any of my messages in this thread

What happens if a JSR changes what's already in JDK 7? by serge ----

The problem with releasing JDK 7 as is is that things might be changed, refined or even dropped as Mark points out. This includes the minor language changes from project coin. This means that you can't actually use them in production because an upgrade to JDK 8 might break them. You ask why? Well there's an implementation with no specification. If a JSR is created the language changes may be ratified or dropped altogether! Oracle would officially have a non compliant version of Java unless they made the changes that came out of the JSR which may or may not break your programs. The risk here as Oracle is not pointing out is that even if coin, jigsaw and project lambda were finished it would be absolute hell for them if a JSR was created and didn’t see platform changes as they did.

The costs and benefots of long delays between major releases by Dean Schulze

ThoughtWorks has put end-of-life for Java as a language on the JVM into the Assess category on their Technology Radar. Long delays in getting major new features into Java are the reason. They like the JVM. It's the Java language that they are concerned about.

I wonder how much the JCP contributes to these delays? The Java community is arguably the greatest strength that Java has, but that collective input and approval comes with a price.

Re: The costs and benefots of long delays between major releases by andrew mcveigh

>ThoughtWorks has put end-of-life for Java as a language on
>the JVM into the Assess category on their Technology Radar.

absolutely absurd.

they also got the GWT radar wrong.

wonder what else they got wrong?

Re: The costs and benefots of long delays between major releases by Nicklas Karlsson

I would consider a language doomed if major new features where added constantly. It appears anyway that any general purpose procedural language will bloat until it looks like C/C++. Just look at the history of PHP.

Re: The costs and benefots of long delays between major releases by prassee sathian

Hi all ,

Its is good time that Oracle has realized the importance of supporting Java language and community. This would likely make the
enterprise players and developers to turn and pay bit attention on this announcement.

Perhaps, the features highlighted as a part of release is not that promising as the JVM languages (SCALA,GROOVY) has these and they provide 100% code compatibility.

The JCP has to be empowered more than ever to get in more features
before the other languages implement it.

However , Thoughtworks radar is more likely to be aligned towards adopting the non-jvm languages like C#,F# because C# is in the adoption circle of their observation.

We still have to wait for much improved JVM to see the java or scala in their adoption circle.

Scala as a language and community is growing steadily, the only lacking factor is the good IDE support.

Re: What happens if a JSR changes what's already in JDK 7? by Peter Kriens

If it would use OSGi, you can have multiple version available to you. So you would get what you depended upon.

Re: What happens if a JSR changes what's already in JDK 7? by Bob Thule

Looking at their little charts, it is clear that Thoughtworks has a Ruby agenda:

1. Thoughtworks is a consultancy company that profits by doing software development
2. There is a lot of competition in Java software consultancy, but almost none for Ruby.
3. Thoughtworks is one of the very few consultant companies that use (and push) Ruby.
4. Companies have a choice of technologies, and when those companies choose Java, then Thoughtworks opportunities are reduced and when those companies choose Ruby, then Thoughtworks opportunities are increased.
5. Java is the most dominant language, so to increase Ruby acceptance and increase their opportunities, then Thoughtworks must try to reduce Java usage (and they do so by spreading fear, uncertainty and doubt).
6. JRuby is one of the most popular Ruby implementations, so Thoughtworks doesn't want to reduce their opportunities by discounting the JVM (that is why they were careful to separate out the Java JVM from the Java language in their ratings).
7. Java is a language that has been around for a long time, and we know that there is nothing wrong with that, but for CEOs who aren't strongly technology minded, they look at other languages like Fortran and Cobol and see that they have come and gone, so it may seem like all languages should have the same fate. And Thoughtworks is playing into that by spread fear, uncertainty and doubt.
8. Java and C# are extremely similar, but Thoughtworks rates C# highly and Java lowly-- they contradicted themselves there. While it is true that recently Java has lagged behind by a few years introducing some new language features, that doesn't make the language dead. Would anybody say that Windows is end-of-life because Windows didn't have many improvements in 10 years (from XP to Windows 7)?
9. It is difficult to use anything but Microsoft products (C#, Visual Studio) to develop for Microsoft platforms, since Ruby is not able to compete with C# on those platforms, and C# is not used significantly on any other platform, then Thoughtworks does not have as much to gain by trying to reduce C# usage.
10. There is a case to for saying that Ruby is at end-of-life: Ruby's hype has been gone for over a year now, and it never gained much industry acceptance-- there are very few jobs available for Ruby.

Maybe what is best is to not do business with Thoughtworks. They may have some very brilliant minds there, but when they are helping you make decisions, will they be looking out for your company's best interest, or for just their own continued profit?

Re: What happens if a JSR changes what's already in JDK 7? by Dean Schulze

Easy, Bob. You're reading a lot into their chart.

Thoughtworks is saying that it is time to Assess the possibility of end-of-life for Java on the JVM.

Re: The costs and benefots of long delays between major releases by Dean Schulze

Scala has to stop breaking backwards-compatibility with new releases, and it needs easier Java interoperability.

Thoughtworks does need to do a better job of explaining its positions on Java and the JVM. If Java is unacceptably slow in adopting new features, which other JVM languages are going to be fast enough for them?

If they are going to keep the JVM what is the way forward if it's not Java?

Re: What happens if a JSR changes what's already in JDK 7? by Arul D

Take the TW report with a grain of salt. It is biased and it is not a surprise when it comes from a vendor. Neo4j, Restfulie mentioned in their Tools graph are some good examples. While, it is easy to put "Java Language end of life" in their graphic, sadly there is no explanation as to why such a position.

Re: What happens if a JSR changes what's already in JDK 7? by Nick Hines

That's funny I don't recall John Waters working for TW.

Re: What happens if a JSR changes what's already in JDK 7? by Bob Thule

Please take another look at their chart: "36. Java language end of life"-- their chart doesn't say "possibility". It also says that Ruby is the most ideal language to start using right now, which most of all know is false.

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

12 Discuss