Java 7 Update


It’s been a long while since I posted any kind of Java 7 update so I thought maybe it was time in case you haven’t been paying attention.

It seems that the dam broke at Devoxx in December. We got some clear direction on the expected timeline and what features will be in and out. There will be a Java 7 preview build available by JavaOne 2009 and theoretically an official Java 7 by January of 2010. I say theoretically because there still seem to be a lot of question marks to fill in pretty quickly.

The Java modularity story got turned upside down yet again. JSR 277 bit the dust and JSR 294 was revived. Project Jigsaw was announced as part of the new focus on modularizing the JDK rather than providing tools for modularizing your apps. This gives Sun a bit more flexibility to work outside the JCP but makes the general applicability a bit more ambiguous. Subsequently, there has been some new and vigorous discussion on the JSR 294 mailing lists where the observer list has been opened to writing. Alex Buckley has provided some initial proposals and Peter Kriens has added a proposal on nesting. Project Jigsaw has been approved. It appears that communication lines are open and work is proceeding.

In the language space, we learned that most importantly closures will not be included in Java 7. Java 7 will also NOT include property support, reified generics, operator overloading, and BigDecimal syntax. That leaves us with the opportunity for a few well-defined, high-value changes and Joe Darcy owns a new Project Coin to accept and process those proposals. At this point some of the most considered are:

A number of polls have now happened to collect information on possible language changes and the null-handling and exception enhancments seem to score consistently high. I agree that these would definitely help but they are small changes.

In the library space, it seems that JSR 203 (NIO2), JSR 308 (Annotations on Types) and some portion of JSR 166 (Concurrency updates) will definitely be included.

JSR 166 has started to narrow down exactly what will be included and the current proposal is the fork/join library but NOT the ParallelArray portions. Java 7 likely will include TransferQueues, Phasers, ConcurrentReferenceHashMap, and possibly a Fences API of some sort. Many of these will seem esoteric to most developers but several are of critical importance to those writing concurrency code.

One of my favorite JSRs, JSR 310 (Date and Time) announced in December that they were running behind and might not make it in time for Java 7. It seems that many people have stepped up to help out based on the mailing list but there is still work to be done. If you have some knowledge in this space or even can just try out the API for your own needs and provide feedback, that would help a lot.

In the Swing space, it seems that JSR 295 (Beans Binding) is out, JSR 296 (Swing Application Framework) is in, and JSR 303 (Bean Validation) is ambiguous. :) JSR 303 recently completed their public review and have collected a lot of feedback from the community but it’s unclear to me what the thinking is from Sun on it.

The new G1 garbage collector seems to finally be reaching stability and will be ported back to JDK 6 in JDK 6u14 in May. G1 is a new concurrent garbage collector designed to take the place of CMS, which many people find problematic. It’s great to have another option in GC.

Last but certainly not least, things are hopping in support for dynamic languages. John Rose is coordinating a whole bunch of sub-projects proceeding in parallel and it’s a feast for JVM-based language implementors. Projects include dynamic invocation, lightweight method handles, lightweight bytecode loading, interface injection, tail calls, continuations, and more. Surely not all of these will make it into Java 7 but some will and they will allow language implementors to do more and do it faster. From a future-looking perspective, these changes are crucial and will allow the JVM to continue to be a place to build great new languages.

All in all, it’s great to see things start to shape up for Java 7! I know some people are disappointed that closures and other features won’t be included. Personally, I think there is a lot of great and compelling stuff here if you’re currently running on Java and the innovative work being done on the JVM makes it a solid choice for new and existing languages moving forward.


21 Responses to “Java 7 Update”
  1. Jonas says:

    Hey Alex.
    Good write up.
    Sorry that I can’t share your enthusiasm over Java 7.
    I think Java is slowly killing itself. Sad but IMHO true.
    Keep it up.

  2. Tom Kramer says:

    Does anybody know what might be the reason for NOT including closures in Java 7?

  3. The link to jsr#294 is pointing to jsr#277

  4. Joejag says:

    Hi, the Java 7 changes along with the suitability of JavaFX were the hot topics at Devoxx 2008. Joshua Bloch and Brian Goetz openly disagreed on the Closure JSRs and everyone seemed a little underwhelmed by the final list of language improvements.

    However, Project Jigsaw and the JVM changes to support dynamic languages are going to very important as they will ensure the JVM survives even if Java itself is falling in popularity/job openings.

    After the JDK7 talk they put up whiteboards where participants could express their feelings around any topics concerning Java. They make a good read:

  5. Alex says:

    @Tom: The stated reason was that there wasn’t agreement on how to implement closures and not time to achieve that. I think that’s a bit of a proxy though for the real issue that there is lack of consensus over whether Java should have closures. More than any other feature, closures have become a polarizing feature – there is a strong segment of the community that actively wants closures (and now) and another strong segment that aren’t just ambivalent but actively do NOT want closures. In the face of that bi-modal distribution it’s a lot easier to punt than to dig in.

    You can find a lot more language polls and other info on language changes here.

  6. Ivan says:

    I really didn’t like any of the closure proposals anyway. When in doubt, leave it out! Goetz && Bloch disagreeing on it is a good sign it wasn’t the right concept. I trust both those guys 100% so I think the right language solution would make them both happy.

  7. The saddest loss to me is ParallelArray from JSR 166. This object makes F/J usable and understandable, which isn’t always true of implementation of the ForkJoin task or RecursiveAction interfaces.

    I’m unclear on your wording about the other 166 features though. Are you saying TransferQueues, Phasers, ConCurrRefHashMap, and Fences will most likely _not_ be in 7?

  8. Alex says:

    @Hamlet: Agreed on ParallelArray although it will be available as a separate library. I’ve gotten over my initial disappointment as that means it can actually evolve faster outside the jdk.

    Sorry if I was unclear on the others – from everything I’ve read they WILL be in Java 7.

  9. Neal Gafter says:

    Regarding ParallelArray, Doug Lea says: “As most people know, existing ForkJoin support consists of two parts, the base ForkJoin{Pool,Task} framework, and the parallel collections (currently only ParallelArray) on top if it. I’m thinking to only recommend inclusion of the base framework into JDK, and to resume working on parallel collections as a non-JDK package. Doing this sidesteps the interface explosion issue (the 96 interfaces like IntAndLongToInt etc etc) and expressiveness issues (closures etc) that make inclusion in JDK hard to argue for, while better motivating development and usage of parallelCollections package over the medium-term future, and as well as possible development of associated IDE support, language extensions and/or other JVM languages”

    The interface explosion issue would have been addressed by BGGA’s function types, and the expressiveness issue by BGGA closures. Doug Lea is a supporter of the draft closures JSR and the exclusion of ParallelArray is in part a reaction to closures not making Java 7.

  10. user says:

    The improved catch clause looks completely unnecessary. I vote against it.

    JSR 310 looks great! I really hope that one makes the deadline.

  11. Tuomas Kiviaho says:

    Does anybody know anything about the current status of JSR-275: Units and Measures?

  12. Alex says:

    @Tuomas: That’s a great question. JSR 275 has a spec and complete reference implementation, so it does not lack for maturity. However, I fail to ever see it mentioned in stuff from Sun which I can only read as disinterest in its inclusion in the JDK. Honestly, it can be used now as a standalone library and I think it itself would benefit little from inclusion in the JDK. There are some cases where the JDK or other JSRs could benefit from it (JSR 310 has some overlap for instance as well as anything defining time units in the JDK). I’m not sure whether those small potential uses justify the addition of the jsr into the JDK proper though. But all of this is my speculation.

  13. Attila Király says:

    No reified generics? :(
    I can’t belive something so important can be droped out. Imho it is something that must be done. As sooner as better.

  14. pp says:

    What is your use case for reification? I have never found a need for new T() that class.newInstance() didn’t satisfy…

    Besides that there are a few irritations with overriding…

  15. Nick says:

    Java seems to be treading water. Aside from relatively low-profile NIO2 stuff most changes are cosmetic at best. It feels as if Sun decided to keep Java as a language in legacy/maintenance mode. Which probably means that they expect something like Scala to take over as the main JVM language.

    It is not necessarily a bad thing but it is interesting to juxtapose with recent developments in much older C++ (i.e. C++0x). In a sense C++ seems to be more vigorous.

  16. Attila Király says:

    To pp:

    I think reified generics is a must with so many scripting languages around (and it would be also good for a lot of frameworks which generate descriptors at runtime).

    Imagine you have a Java code with a List of Integer-s. You make it in Java, you iterate it in Java too. However you can put anything into it with a script. The error will be thrown at the place you try to use it, not at the place, where you added a non Integer to it. Not good.

    For example in this you get an error at the iteration, not in the javascript:
    List a = new LinkedList();
    SimpleBindings bindings = new SimpleBindings();
    bindings.put(“a”, a);
    new ScriptEngineManager().getEngineByName(“JavaScript”).eval(“a.add(\”a\”);”, bindings);
    for (int i : a)

    If you use an array instead of a List the error will be thrown in the javascript and not in the iteration.
    int[] a = new int[1];
    SimpleBindings bindings = new SimpleBindings();
    bindings.put(“a”, a);
    new ScriptEngineManager().getEngineByName(“JavaScript”).eval(“a[0] = \”a\”;”, bindings);
    for (int i : a)

  17. I doubt that the JSR 296 will be in Java 7. There’s no activity in the EG nor in the public project.

  18. Alex says:

    @Karsten: I was mildly surprised too. Mark Reinhold said at Devoxx in Dec 08 that it would be included. And Danny Coward repeated that on his blog recently, so I’m assuming something will be in Java 7.

  19. Eric says:

    This is gonna sound crazy (and maybe sound a little like a manager type talking) but does anyone out there somewhere have any sort of Work Breakdown Structure (WBS) and/or “Project” Schedule showing all the expected components and their status (% complete, planned time, etc) for Java7? If such a thing existed then people could track the progress of the whole thing a little easier.

  20. Alex says:

    @Eric: Ha, that is crazy. While I’m sure there is some such schedule somewhere I can’t imagine it being made public. At this point, we’re still really guessing as to what will actually be included. I’m studying and reading the tea leaves more than most but technically the platform JSR will make things concrete. Most of the JDK modifications mentioned above have an existing spec, an expert group, and a functioning implementation, so in that sense they are relatively mature. The modularity stuff is still in heavy flux and the small language changes are really just getting started. The JVM dynamic language work is all occurring in the Da Vinci machine project and that plus the tracking make it relatively visible.

  21. Tuomas Kiviaho says:

    @Alex: I noticed that JSR-275 has also inactive status just like JSR-296.