People have been asking me about the plan for Java 7 with relative frequency lately so I thought I would try to summarize what we know and what we don’t. [I maintain a somewhat out of date Java 7 page and a blog of incoming Java 7 links].

Terms

Before I go any further, I should point out that I will very intentionally and non-interchangeably using the terms “Java 7” and “JDK 7” in this blog post. By “Java 7” I mean the official specification as defined by the JCP. The JCP creates specifications by creating a JSR that can be approved by the appropriate Executive Committee. Each specification includes the spec, a reference implementation, and a test compatibility kit that verifies the RI implements the spec. To have a Java 7 specification, there must be an umbrella JSR for it (like for Java 5 and Java 6).

By the informal term “JDK 7”, I really mean the current work being done (primarily by Oracle/Sun) in the OpenJDK JDK 7 project. The OpenJDK (and before it the Sun JDK) has historically been the official Reference Implementation for the specification as defined by the JCP. As such, JDK 7 is simply “an” implementation, not “the” implementation. IBM will have their own implementation (presumably) as will Apache Harmony, Apple (largely a licensed version of the Sun impl), etc.

Messy stuff

The current situation is a bit weird, and made weirder by the Oracle acquisition of Sun. There has been a long-standing dispute between Sun and Apache over the “field of use” terms in licensing the JDK Specification TCK. This has been reported with great clarity by Stephen Colebourne using publicly available documents. [The rumored reason behind all this maneuvering is said to be a reluctance to give Apache Harmony a level playing field because this would hurt Sun’s Java ME licensing revenue (also note Google using Dalvik for Android rather than JavaME). But that’s all rumor and speculation afaik.]

Anyhow, due to this dispute and undoubtedly other factors, a Java 7 JSR has never been submitted by Sun or Oracle to the JCP. The engineers at Sun weren’t going to sit around doing nothing so started working ahead on planned features of Java 7 in the OpenJDK JDK 7 project. In the meantime we had the acquisition and all sorts of technical project management decisions (closures out, closures in, etc etc). We now find things at a point where the implementation is significantly far along (much of it happening under feature-level specs like JSR 203, 308, etc) but there is no official proposed definition of the specification.

Schedule

The currently published calendar for JDK 7 states that JDK 7 will be feature complete on June 3, 2010 (hey that’s 2 days from now!) and the last dev milestone is targeted at Sept 9, 2010 (conveniently located right before the first Oracle-led JavaOne) with a period following for stabilization and testing. If we believe this schedule, then JDK 7 should be finished by somewhere at the end of the year.

But that’s JDK 7. It’s hard to see how you can “release” a JDK 7 without somehow resolving the issue of the Java 7 specification. Otherwise there is no “standard Java”, no “write once, run anywhere”, no defined set of features that other JDK/JVM implementors must implement. I can’t possibly imagine that as being a useful outcome for Oracle, given their dependence on enterprise Java middleware.

Next steps

We’ve been in a bit of a drought for official Java news, with not much coming out from the traditional luminaries like Danny Coward, Mark Reinhold, or Alex Buckley. We are seeing continuing work with interesting specs from Brian Goetz on virtual extension methods and lambda translations, lambda/closure work from Mark, various Project Coin feature implementations from Joe Darcy and others, etc.

I’m hoping that there will be some forthcoming news soon about where Oracle plans to take the JCP (since it controls the executive committees) and the Java 7 specification.