Java 7 Prediction Update

15

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).

Comments

15 Responses to “Java 7 Prediction Update”
  1. sboulay says:

    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.

  2. Alex says:

    @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.

  3. david says:

    I really like the notion of “JSR 275 Units and Quantities”, but I’d rather wait and get something decent instead of rushing it.

  4. Casper says:

    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.

  5. Nate says:

    These would make great prediction market questions. You should stick them up on home.inklingmarkets.com.

  6. GeekyCoder says:

    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.

  7. Paul A Houle says:

    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.

  8. Sidewinder128 says:

    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.

  9. Alex says:

    Don’t forget that this is just my conjecture and things like type inference, closures, and more could still be included.

  10. 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.

  11. 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?

  12. Alex says:

    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.

  13. Dennis says:

    Regarding closures, I never really liked most of the proposals. I’ve been gravitating more toward Groovy day by day anyway.

  14. Red Royal says:

    its quite need document.. thanks for everything..

  15. rtra says:

    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 .