Mark Reinhold just published a blog stating what has been painfully obvious to everyone following the JDK 7 development: There is no way that it will ship 2010. He thinks that mid-2012 would be realistic. Having followed the Project λ discussion, I can see where he is coming from.
He asks whether Oracle should just package up what is already finished, run it through QA, and slap a Java SE 7 label on it (presumably after having it rubber-stamped by a JSR). Java SE 8 could come at the end of 2012, coinciding with the end of the Mayan long count.
To nobody's surprise, almost everyone replied that it is better to have something now than maybe have something better later.
What will be in Java SE 7? Here is the list, to the best of my knowledge, sorted in the order in which they matter to me :-)
invokedynamic and an API for method handles. (I'd rate this
higher if I knew What is missing?
Now, this isn't the end of the world. Look at the Wikipedia Java version history: The most notable Java 1.3 enhancements, besides HotSpot, were JNDI, Java Sound, and CORBA support in RMI. Not exactly earth-shattering stuff, but at the time nobody complained about Java turning into COBOL.
I think what really made people unhappy is not the modest Java 7 feature set but the five year gap since Java 6. But that's water under the bridge. It's more useful to think about where we are going. Here I am only talking about Java SE, not EE or ME.
The Java language is now pretty much at the end of its evolutionary path. Sure, some form of closures will be nice, if and when they come. But the people who care about this kind of stuff have other choices, both on and off the JVM. I have no problem with that.
On the JVM, there is still quite a bit work that can and should be tackled—see this blog.
Where we are hurting are the Java libraries. They haven't seen much love for a long time. There is a good amount of cruft all over, not just in the date/time API. Client-side UI development is in particularly bad shape. I'd like a much richer set of Swing controls than what I had in 2002, an app framework that's at least as good as MFC was 20 years ago, and audio and video that actually works. And, no, I do not want another language to write my UI. If there is anything useful in JavaFX (such as the scene graph), port it back to Java SE! And, of course, fix deployment!!! On my Windows 7 laptop, I am still getting an error message (download of the latest Java version failed) whenever I click on that orange tray icon.
Another pet peeve of mine is the WebStart API. WebStart-in-a-sandbox is a great idea, but it can only work if the sandbox works well. Making users accept "all permission" negates one of the primary benefits of using Java in the first place. I want an API that “just works” when my app runs in the sandbox—today that's only the case for printing. And I want the kind of friendly end-user permission management that cell phone apps have these days.
There is still a window of opportunity for Java to regain traction in the cross-platform desktop space. Everyone loves to bash Swing, but if you need to bang out a cross-platform app that gets lots of data from the user (as opposed to having lots of eye candy), then Swing is pretty good. And there isn't a lot of credible competition: Qt, wxWidgets, pyGTK, or Mono/WinForms aren't exactly a walk in the park either. But that window will close. (BTW, I didn't think it was a good sign that the GlassFish update tool was written with wxWidgets.)
In summary, I am ok with a modest Java 7. I am ok with a Java language that won't evolve much more. But if the Java library doesn't evolve with the times, there is trouble ahead. In particular, on the desktop, the time has come to put up or shut up.