BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Java 7 Roadmap Updated: Reactions

Java 7 Roadmap Updated: Reactions

Leia em Português

This item in japanese

Bookmarks

During Devoxx Mark Reinhold, Chief Engineer for Java SE, gave a presentation about the latest directions for Java 7, alongside a release date in early 2010. Although Mark described his presentation as a provisional plan and not binding, there have been many reactions from the community, especially regarding the omission of Closures.

Hamlet D'Arcy who attended Devoxx, provides a summary of Mark’s presentation about the features of Java 7. Some of the more important changes he outlines are:

Modularization - 294 and project Jigsaw

292 - JVM Support for dynamic languages

JSR 203 - More New I/O APIs which are nearly finished, includes true asynchronous I/O (not just non blocking I/O) and finally a real file system API

JSR TBD: Small language changes (following)

Safe rethrow - Allows a broad catch clause, with the compiler being smarter on what you're allowed to rethrow based on what is thrown from the try block. (I had not seen this before but it looks nice)

Null dereference expressions - Null checks with '?' syntax similar to Groovy... lettign developers avoid a nest of null checks.

Better type inference - Example around generics instantiations, but it was not clear how far the inference would be taken (the more the better in my opinion).

Multi-catch - (yes!) allows a comma seperated list of disjunctive exception types in catch clause.

Joe Darcy is leading effort in Open JDK and his blog was referenced: http://blogs.sun.com/darcy

JSR 296 - Swing application framework - It still needs to be easier to create Swing apps.

A forward port of 6u10 features (Java Kernal, QUickstarter, New Plug-in, etc.)

He also mentions several features that were considered for Java, but will probably not be part of version 7:

    Closures - No consensus around single proposal

    Reified generics

    1st class properties

    Operator overloading

    BigDecimal syntax

    JSR 295 - Beans Binding

Java.net runs a poll regarding “Which of these excluded-from-Java-7 features were you most interested in” and at the time of this writing Closures are clearly ahead of all other fetures:

Closures               					47.4% (734 Votes)
Reified generics    					17.2% (266 Votes)
First-class properties  				10.4% (162 Votes)
Operator overloading    				4.3% (67 Votes)
BigDecimal syntax      					3.4% (54 Votes)
JSR-295 Beans Binding  					7.3% (113 Votes)
I wasn't interested in any of these			9.7% (150 Votes)

Ricky Clarkson believes that without Closures Java is “dead”:

So it's confirmed. Despite James Gosling wanting closures, despite 3 working closure prototype compilers, despite every other JVM language supporting closures, Java 7 will not have closures.

Martin Kneissl also feels no Closures in Java 7 is bad news:

It should have closures instead of the new style "for" loop added in Java 5. It should have closures in Java 6. Now it seems that it will not get closures in Java 7.

Closures are not that difficult to understand. At least when you compare them to anonymous inner classes in Java. Others disagree. I don't follow the reasoning of the closure opponents when they say that because there are stupid Java programmers out there you should limit the Language trying to prevent them from doing too much harm. That's just impossible. Incompetent programmers will shoot themselves in the foot in any language.

Fortunately there are other languages on the JVM that can use the real strength of Java: libraries, portability, and (to some extent) tooling.

Dustin Marx, is a bit more ambivalent about Closures on his post about most-missed Java 7 features:

As of this writing, there are just over 160 votes (but new votes are coming in fairly rapidly right now) and the far-and-away leader for most missed dropped feature from Java SE 7 is closures. At this point, the closures feature has received relatively close to half of the total votes. In one respect, this is to be expected. Closures have seemed to dominate the Java SE 7 discussions until it was announced that they would not be included in Java SE 7. However, some of the reason for this significant discussion is the controversy surrounding both the concept of having closures at all as well as how closures would be implemented.

While closures have been one of the most hotly discussed proposals for Java SE 7, I have personally been fairly ambivalent about them. I can see how they would occasionally be useful in my work, but I can live without them for the most part. In other words, I wouldn't mind if they were added, but it did not really bother me when I heard that they would not be included in Java SE 7. However, if we are to believe the results of this poll so far, close to one half of Java developers wanted this feature the most. This is in line with a previous Java.net poll question regarding developers wanting the closures question resolved in time for Java SE 7.

Osvaldo Doederlein is excited about the new features, but still misses Closures:

Java7 will be the best release in many years infrastructure-wise: 294/Jigsaw; Concurrent classloading - I think that could speed up the boot time of large apps, especially microkernel-based ones like JavaEE servers and IDEs; XRender - will finally make Java a first-class citizen for Linux desktop apps; G1; Full 64 bit support (will actually debut in 6u12, get the beta); ForkJoin.

So much good stuff, I can almost forget the sadness of probably not having Closures. I guess it's time to move to Scala, JavaFX or some other modern JVM language (just not dynamically typed crap like Ruby or Python). I think that five years from now, I'll only be writing 'standard' Java code if I'm writing a low-level runtime of some sort (middlewares etc). Thanks to the conservadorism of the community, the Java language is slowing moving into legacy and low-level roles.

On the other hand Matt Grommes focuses the BigDecimal syntax:

I’ve been working on a financial system for over a year and the BigDecimal syntax is insanely painful. I’m really not happy about this.

Stephen Colebourne presented the audiences of Devoxx and JavaEdge with 10 possible language changes for JDK7 and asked them to vote:

There is a clear winner - null handling. Null handling had 50 first preference votes, double that of second place string switch and almost a third of all first preferences. This trend continued with almost two thirds placing it in their top four.

Other popular options were String Switch, Multi-catch of exceptions, enhanced for-each loop for Maps, enhancing the for-each loop to be able to remove or find the index and ARM-style resource management.

Unpopular options (especially considering the black 'bad idea' values) were List/Map access using [] and String interpolation (${variable} in strings).

Infer generics and multi-line strings were deemed of relatvely low importance but not particularly objectionable.

It should be noted that in Devoxx the vote on closures was split 50/50.

You can find more information on the next generation of Java SE platform right here on InfoQ.

Rate this Article

Adoption
Style

BT