It’s been clear for some time that the most recent JDK 7 development schedule is, to put it mildly, unrealistic.
We created that schedule over nine months ago, prior to the acquisition of Sun by Oracle. The post-acquisition integration process took longer than any of us anticipated, unfortunately, but we’re now ready and able to focus on this release with a larger (and still growing) staff which will continue to work in the open alongside other contributors.
So, whither JDK 7?
Our present best estimate is that we could complete, test, and stabilize the planned work in time for a release around the middle of 2012.
Looking at what’s in the forest today, however, much of that work is in fact already done, or very nearly so. The main outstanding items are the Lambda and Jigsaw Projects, along with a few of the Coin proposals. We’ve made a lot of progress on these features, and they now have more Oracle engineers working on them than before, but significant work remains to be done.
Another possibility, therefore, is to take everything we have now, test and stabilize it, and ship that as JDK 7. We could then finish Lambda, Jigsaw, the rest of Coin, and maybe a few additional key features in a JDK 8 release which would ship fairly soon thereafter.
This approach would give developers production-quality access to the nearly-finished features sooner rather than later, and with much less risk. It would also allow more time to really shake out Lambda and Jigsaw, which is critical given that these higher-risk efforts are making deep changes to the very foundations of the platform.
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.
Plan A: JDK 7 (as currently defined) Mid 2012 Plan B: JDK 7 (minus Lambda, Jigsaw, and part of Coin) Mid 2011 JDK 8 (Lambda, Jigsaw, the rest of Coin, ++) Late 2012
(As always, our intent is that JDK 7 will ship concurrently with a Java SE 7 JSR, and likewise for JDK 8 and Java SE 8, and also that there will be JSRs for Lambda and Coin.)
Here at Oracle we’re leaning heavily toward the lower-risk Plan B. The platform has been idle for (more than!) long enough—it’s time to get Java moving again. If there are good reasons to prefer Plan A, however, then I’d like to hear them.