Java 7 Prediction Update
I just realized due to a forum thread that it’s been about 7 months since I posted my Java 7 Predictions. So, it seems like a good time to update those predictions.
At the time I was expecting that the Java SE 7 JSR would be created before JavaOne 2008 but obviously that didn’t happen and we’re still waiting for the JSR. Waiting on what, I’m not really sure. I know the open source effort and subsequent JavaFX in Java 6 work has been soaking up a lot of focus, but seems like it’s still a bit late. Maybe it’s on vacation for the summer.
Anyhow, I’m going to organize this a bit differently this time by putting stuff in three categories – Likely, Possible, and Unlikely. As always, these are my own opinions based on stuff I’ve read although I talk to various spec leads and members occasionally, you should trust this about as much as anything you read on the net. Also, these don’t reflect what I’d like to see, just what I think is most likely.
Likely
| Feature | Chance | Comment |
|---|---|---|
| JSR 294 Superpackages | 95% | Sun’s going to push this in |
| JSR 277 Java Modules | 95% | ditto above |
| JSR 203 NIO 2 | 99% | Solid. |
| JSR 310 Date and Time | 95% | Very good shape |
| JSR 166 Concurrency Utils | 95% | fork/join plus some additions |
| JSR 225 XQuery API for Java | 90% | Pretty far advanced |
| JSR 296 Swing App Framework | 90% | Interrupted due to spec lead’s departure but I think it will get picked up again |
| JSR 295 Beans Binding | 95% | Looking good, responded well to early criticism |
| JSR 303 Beans Validation | 90% | Has solidified since last predictions |
| Java Media Components | 80% | Partially done in JDK 6 update |
| JSR 255 JMX 2.0 | 99% | Ready |
| JSR 262 Web Services Connector for JMX | 99% | Available now |
| JSR 308 Type Annotations | 80% | Prototype available now |
| Strings in switch | 70% | Easy and useful |
| Comparisons for Enum | 80% | Useful extension of enums |
| Improved catch | 80% | Seems to have a lot of support |
| JSR 292 invokedynamic | 95% | Likely to be some changes to better support dynamic languages |
| Tiered compilation | 70% | Work on this seems active enough that there will be some updates in this area, although it’s difficult to tell exactly what that will mean. |
| G1 garbage collector | 90% | Far along |
Possible
| Feature | Chance | Comment |
|---|---|---|
| JSR 275 Units and Quantities | 60% | Well defined, but I’m not sure this will be included in the actual JDK |
| JSR 284 Resource Consumption Management | 50% | Hard to judge this one – there is a proposed final spec and seemingly interested support from major players, but not too much info out there. |
| JSR 326 Post Mortem JVM Diagnostics API | 40% | Depends on timing, just starting now so would depend on JSR moving fast and Java 7 moving slow |
| Type Literals | 40% | I think some useful class or reflective helper will be added as a small stopgap to no reified generics. |
| Type Inference | 40% | Possible but hard to tell |
Unlikely
| Feature | Chance | Comment |
|---|---|---|
| JSR 107 Cache API | 0% | Hard to find anyone that cares |
| JSR 260 Javadoc Update | 5% | Totally undefined |
| Reified Generics | 5% | Highly unlikely at this point |
| Closures | 20% | Still seems possible, but I don’t think any major language changes like this are going to be included |
| ARM Blocks | 10% | Seems unlikely |
| XML Support | 0% | Not a chance |
| Property support | 5% | Nobody pushing this much anymore |
| BigDecimal operator support | 5% | Lots of interest, but apparently would introduce compatibility issues |
| Chained invocations | 20% | Seems unlikely at this point |
| Extension methods | 20% | Motivation low without closures |
If you’re interested in watching the Java 7 space, check out my Java 7 link blog (RSS).
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Gee, I was really hoping that some form of closures would make it into java 7. Even if closures were included in java 8, we wouldn’t see any real adoption until 2015 – now is the time to add them. I fear that people we’ll start to get feed up with writing boilerplate code and leave for languages that are more concise.
@sboulay: Well, me too. But I get the feeling that Java 7 is not going to include major language changes. I’m thinking more that it will bundle up the mostly done library stuff and shoot for an earlier release.
I really like the notion of “JSR 275 Units and Quantities”, but I’d rather wait and get something decent instead of rushing it.
Can anybody explain the rationally behind not including a variation of ARM since it’s so simple yet useful. Sure it can be done with closures, but there’s precedence to this in the foreach construct which everybody loves. The C# using statement is one reason why their API’s are just more programmer friendly.
These would make great prediction market questions. You should stick them up on home.inklingmarkets.com.
If closure is going to be included sooner or later, why not Java do it at Java7 ? This really fathom me as radical changes are bound to happen and Java7 should take this opportunity especially Ruby, Python, PHP, Perl are making radical change as well.
Will closure be useful and adopted ? One never knows until it is put into market just like Generics, variable argument. I yet to find any language changes make so far negative. Instead if one takes a open mind, the change is all the more useful and purposeful.
That to say, Closure is a enhancement that I greatly look forward to.
Closures are big. I’ve been looking at the way that C# has been making functional programming ideas mainstream, and I’m finally starting to agree that delegates were the right decision.
This is a shame, a disaster for Java, I was waiting type inference, closures, Arm and reified generics and nothing of this will make it, Also why superpackages this is retard, OSGI is better. Java is doomed, Java its dead.
The ISO C++x0, will have the next year, type inference, closures, concurrency, optional garbarge collector and many goodies, I think C++ will be more capable language than Java. I will have to clean up my C++ books, oh yeah babe C++ again.
Also I don’t want to use scripting languages for closures and so on over JVM because it feels slow and bloated.
I think is coming an IT storm switch of languages, with C++, Erlang, C#, Python, Ruby, PHP are more capable than Java.
Long live Java.
Don’t forget that this is just my conjecture and things like type inference, closures, and more could still be included.
I still hope property support will be a part of Java soon, because that could make client code a lot more readable, and that is what I need most of the time. :)
On the other hand I think that the current focus on JavaFX and related stuff is the right thing to do.
Hi Alex, I don’t suppose you happen to have the ear of someone at Sun. I’d love to know what they make of this whole closures debate, if they are even aware of it?
Well, I don’t think anyone from Sun would listen to me. :) But, you can listen to this JavaPosse interview with Danny Coward (who would create the Java SE 7 JSR). He talks about closures a little.
Regarding closures, I never really liked most of the proposals. I’ve been gravitating more toward Groovy day by day anyway.
its quite need document.. thanks for everything..
Boy, did those predictions make me sad. During the last days I’ve been trying do decide which language I should pick up as my main tool, because I need to enter the job market. I don’t want to adopt a cosed proprietary plataform, so C# on .NET is out of the question; I’d like to go with Java, since its platform is both powerful and very convinient for cross-plataform deployment. Sun’s OSS strategy is also a strong appeal, since I’m in great debt to OSS, but withtout most of the ‘unlikely’ features, I’m going to look elsewhere, and C++x0 is the strongest candidate, right now.
I guess Java is living up to its fame, and that’s sad .