SQL Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

Oracle "Leaning Heavily" Towards JDK 7/JDK 8 Feature Split

  • submit to reddit
We've all known for some time that the JDK 7 development schedule was a bit too ambitious given the sudden addition of closures and the re-structuring after the Oracle acquisition.  Having been written 'pre-acquisition', the initial JDK 7 roadmap looked unrealistic even in late 2009.  So what does this mean?  More delays?  Not necessarily, says Mark Rienhold.  

Today, Oracle's Chief Architect in the Java Platform Group proposed two options for the JDK moving forward.  The first option, "Plan A," would keep all of the currently defined JDK 7 features (including Project Lambda, Coin, and Jigsaw) within the same release.  Under this plan, the final release of JDK 7 (and Java SE 7) would be pushed back to mid-2012.

Plan B, the plan that Reinhold and others at Oracle are "leaning heavily toward," would split the release in two.  JDK 7 would include many features that are close to being finished.  The benefit of separating Lambda, Jigsaw, and parts of Coin into a second release is the greater amount of time that project developers would have to work on those pieces.  These major features (remember, Lambda was started late last year) still require significant work, and they could potentially turn out better if they're not rushed out the door.  Plan B would allow JDK 7 to arrive midway through 2011.  JDK 8, which would include the features that need more work, could be expected in late 2012.

Under Plan B, JDK 7 would include:

  • Most of Coin (haven't determined exactly which parts would be bundled with JDK 7)
  • NIO.2 (JSR 203)
  • InvokeDynamic (JSR 292)
  • "JSR 166y" (fork/join, etc.)
  • Mostly everything else on the feature list minus Lambda, Jigsaw, and parts of Coin
  • Possibly a few additional features

JDK 8 would include:

  • Project Lambda (closures)
  • Project Jigsaw (low-level module system)
  • The rest of Project Coin
  • Additional features

In February, during an Oracle Tech Chat, Reinhold said that the schedule for JDK 7 was extended far enough so that they wouldn't have to introduce closures in JDK 8.  Now the JDK 7/JDK 8 split seems to be the option his team is favoring in order for Java to continue to show signs of life.  It also doesn't make sense to let the nearly-finished features collect dust while we wait for the other features to catch up.  

Some of the commenters were understandably upset with the further delays in JDK 7.  Even if Plan B is adopted, it will still be another year before it's finished.  It's good that Reinhold indicates that the JCP process will still be observed going forward, but I can think of at least one member of the JCP that might vote against anything Oracle proposes.  

Jan-Kees van Andel suggested in the comments that Plan B might cause a majority of companies to skip upgrading to Java 7 if Java 8 is scheduled less than two years after JDK 7.  On the other hand Brian Goetz, an Oracle engineer,  believes that JDK 7 will be widely adopted because it's considered a small release.  He compares the situation to Java 5's release, which was considered "big".  Many companies were slow to adopt 5 or just skipped over it until Java 6, which people considered a "small" release, according to Goetz.

DZone will keep you updated on any developments related to JDK 7 development.

Update: Joseph D. Darcy posted all of the possible features in Project Coin that could be included in JDK 7 under Plan B.  Anything else, we assume, would be in JDK 8.

Here are the features he listed:


Jacek Furmankiewicz replied on Wed, 2010/09/08 - 3:47pm

Wasn't the whole point of Lambda the fact that the fork/join API would be atrociously verbose without it? I recall that from Mark Rienhold's original "closures for Java" annoucement...

I guess more time for Scala to gain a foothold before Java gets lambdas :-)

Richard Osbaldeston replied on Wed, 2010/09/08 - 4:19pm

Wasn't jigsaw and small coin changes the cut down JDK in place of full blown JSR277, JSR294 module system? Seems like not using the JCP to speed up development after JDK7 was delayed 12 months last year really worked out well. Kinda wondering when are Oracle going to wade in and sort out the JCP vacuum as show some leadership and roadmap here, hell even a independent Java foundation might be worth a shot.

So are the JSRs that where dropped from the original JDK7 back in the game? JSR310, JSR295 & JSR296? dropped due to 'lack of time' (ahem - just before the last delay). I'd sooner see those than somebody thinking up new small coins to go fishing for.

Don't get the Gotez argument here is two major JDK releases (version numbers) a year apart really better than one? Is not knowing what's going into the core platform from week to week an open platform for the future? Sounds like plan B is just lame marketing/naming trick.

Ugh what a mess. Real kick in the nuts for JavaFX which no doubt needs the cutdown jigsaw profiles more than anybody (though thats still no Dalvik/MVM). Like the patent issues with Google it's another letdown Java doesn't need right now.

Sneaky trick leaking this before JavaOne, saves getting pelted with shoes I suppose. What are they going to announce now? nothing to see here come back in two years?

Mikael Grev replied on Wed, 2010/09/08 - 4:35pm

I don't get the math.

A normal major revision for Java cycle is 18 months, or so the goal is. JDK 7 plan A has been in the works for a few years and most things are done. Only a few ones, Lambdas and Jigsaw (not small but has been worked on for some time now), remain.

So, to complete the last 30 (or so) percent takes 21 months according to Plan A. This is more than a normal full release cycle! It's almost as long as 1.4 -> 5.0 which was a really big change.

If this was because the work force were being severly reduced I would understand it somewhat, but Mark sais that the work force is larger now and growing. The merger shouldn't affect technical work like this either, unless all developers needs to convert to JDeveloper of course. ;)

It shouldn't have to take almost two years to complete the last bits. Two years in IT-time is a really really long time. Complete languages has been build in less time.

Hence, I don't get the math.


Craig Ringer replied on Wed, 2010/09/08 - 8:48pm

.... and all of this delays any hope of language-level properties or some of the other language cleanups that the first pass project coin missed.

At least Java EE 6 is progressing nicely, being largely free of the mire of JDK7 development.

Guido Amabili replied on Thu, 2010/09/09 - 12:18am

Hopefully the Eclipse Foundation will fix their Oracle namespace and properties bug as Oracle plans even more innovations.

Jan Kotek replied on Thu, 2010/09/09 - 5:55am

Good I learned Scala :-)

Jan Goyvaerts replied on Thu, 2010/09/09 - 6:34am

If one has to chose right here right now, I think the "B" option would be preferable. But what Oracle's word worth today ? Being customer-centric as they are, I don't think their prime concern would to be to release an new version of JDK - just to please a bunch weird nerds. I think the past events proved that point already. So really, what can we expect them to do in the years to come to develop Java ?

Henk De Boer replied on Thu, 2010/09/09 - 4:38pm in response to: Jacek Furmankiewicz

Wasn't the whole point of Lambda the fact that the fork/join API would be atrociously verbose without it?

As I recall it, specifically parallel array would be quite verbose without it. The general fork/join framework still works acceptably with regular Java code.

Les Stroud replied on Tue, 2010/09/14 - 3:54pm


First the schedule slips a year. Now, they are not much further (from a feature perspective) and it slips another year and a half. This wreaks of over process (or maybe just process flux). I am sure this is merger related, but this kind of delay could be devastating for Java the language. By the time this is released, there will be a couple of new languages, Go will be mature, Ruby will be entrenched, scala will reach maturity...etc.

Belief about Oracle's ability to govern Java may be irrelevant, their management of the merger process may kill it before they start demonstrating direction. (i am defining kill as moving from the growth corner to the maintenance corner of a technology plan)

I have to say, this is more than a little disappointing with expectations of a release candidate at JavaOne.

Gar Labs replied on Tue, 2011/08/23 - 10:41am

Plan B! I would like to see lambdas in this release. -GAR Labs



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.