Ready for InfoQ 3.0? Try the new design and let us know what you think!

Java 7 Roadmap Updated: Reactions

| by Dio Synodinos Follow 4 Followers on Jan 02, 2009. Estimated reading time: 5 minutes |

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:

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 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 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 Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Ah... the culture of Java. by Vic _

Funny thing about Java, it's "what you can ADD to it" culture.
How can we add this, that, make it a submarine that is also a lawn mower, by just adding this blade here.

Some programmers from the non-Java culture talk about... shock: removing/deprecating bloat features and that ... crazy people: less features would make it more useful. Focusing on what could be removed.
I know, crazy talk. Now back to: What else can we add to a dead lang. Closures are nice to be suyre. Do we beed built in xml, beans, omg, corba, swing... built in? Not use a 3rd party lib instead when needed?

Forces a start from scratch .... w/ D? Haskel? Lua? Erlang? ActionScript? Who is the new king?

what are the real reasons for closures not being included? by Jesse Kuhnert

I know everyone has an opinion on this and I've been fairly vocal myself but I'm starting to lean more and more towards thinking that Sun either doesn't have the resources to implement the changes or someone high up enough in the organization either just doesn't care or is being influenced by non-academic reasons that we're unaware of.

Hell, even objective-c is adding closures in now.

The arguments about which proposal is best are also equally disturbing / confusing. If you look at the names on the BGGA proposal and do a little background research you'll find that these guys aren't f-ing around when it comes to tinkering with programming languages. You'd think that the creator of the language would get a little more respect for his opinions than he has. Could only happen in the java world I guess huh?

As a participant in Java SE 6 by Steve Jones

When the completely insane decision to add JAX-WS was made (how dumb does that decision look today?) I will say that Mark is unlikely to listen to any real debate over what goes in beyond this list and will aim to rail-road it through.

OSGi should be the modularisation and its time to get RID of loads of stuff so those of us who build large scale enterprise applications don't have it hanging around.

New Swing stuff... give me a jar file don't give it me in the basic library set.

Java needs to split into a lightweight core, a desktop edition, a "RIA" edition (ala applet++ edition) and the enterprise edition. Folks doing JRuby and the like and just take the lightweight version. Those doing Spring (without JEE) can just take that same core and those building JEE don't have to be burdened with either the "SE" JAX-WS libraries (and web server) or with the MIDI libraries that are still in there.

This is highly unlikely to happen however under the current regime and I used the term deliberately.

Java 7 feature list are *proposed* features by Charles Nutter

I believe only JSR 292 (invokedynamic) and the modularization stuff are officially supposed to be "in". The other "small language changes" are all simply proposed changes, and the majority will not be in.

And for everyone moaning about's not as simple as "just add them". There was vast disagreement about which of the proposals to go with or whether it should be there at all. And unlike languages like ObjC or C#, there's already a wealth of fast, production-quality dynamic, static, and functional languages available on the JVM that do have closures. Shoehorning them into Java wouldn't really have accomplished a whole lot.

Re: As a participant in Java SE 6 by Ronald Miura

The JRE being downloaded in chunks (the Java Kernel thing) is not related with the modularization talk, which includes OSGi in the discussion. 'Modularization' is a compile/packaging/run-time capability to enforce well-defined boundaries between the so-called modules. One does not imply the other, since the first is just an implementation detail (note that JRE chunks are already is downloaded on demand), and modularization requires spec changes in both API and VM.

About the split in these various editions, isn't this already done with Java Kernel? If a user only uses the 'lightweight core' part of the JRE, only this will be downloaded. If for this user installs Netbeans, the full Swing package will be downloaded, and so on. Maybe *Sun's implementation* of the JRE does not let them to break it into fine grained pieces, but again, it's an implementation detail, not a reason to change any spec or create any other 'edition' of the JRE.

Re: Java 7 feature list are *proposed* features by serge ----

I have to respectfully disagree with you Charles. It’s simple not that easy for shops to switch to new languages on the vm just to get a couple of productivity features. There are still a lot of people who use “Java the language” who would benefit from small/medium and in some cases large language changes. What’s the future of “Java the Language” if it won’t evolve? Perhaps it’s in the platform? What are you thoughts?

Java 7 Language Changes Poll à la Devoxx by David Linsin

When Stephen Colebourne published the results of the Devoxx whiteboard poll on Java 7 language changes, I had the idea of doing the same poll on my blog. I know there are other polls and blog posts on the proposed changes out there, but I think it would be valuable input for Sun to hear even more voices. If you are interested leave your vote on my blog.

Additional Features by poplularity by Dan Howard

Closures - why do people keep crying about this? Use Groovy or Rhino or JRuby, etc... The reason this one didn't make is because there were 2 different proposals by 2 java titans: Gosling and Bloch. Ego counts. Bloch's design is simpler therefore better)

Reified generics - Should be the most popular choice.

First-class properties - Bad idea. Java should not become a kitchen sink language like C#.

Operator overloading - REALLY Bad idea. Hurts code readability and was the primary cause for the destruction of SmallTalk back in the 90's. Why repeat the same mistakes like C# did?

BigDecimal syntax - not very important but a nice-to-have.

JSR-295 Beans Binding - yawn.

Re: As a participant in Java SE 6 by Steve Jones

The current "lightweight core" of JavaSE includes (and this is far from an exhaustive list)

JAX-WS (with "lightweight webserver)
Scripting support

Which are far from needed by all applications.

The modularisation piece is exactly related to this problem of JavaSE being in reality Sun's vision of a Desktop platform rather than actually being a lightweight core. To be compliant a distro has to ship all of these bits and a server has to have them all there already (dynamic download of big chunks not being the smartest idea in a high performance server environment).

Modularisation and profiles would have a been a great and radical departure for Java and one that is required.

Re: Additional Features by poplularity by Rhys Parsons

Why are first-class properties a bad idea?

Properties in Java are *so* important, and yet they have no presence in the language, only in the APIs. In my humble opinion, a syntax for declaring properties would have the merit of being clear and concise without changing the underlying semantics.

It's not about becoming a 'kitchen-sink' language. It's about evolving the language so that a program can be more transparent about its intent. Writing getXXX() and setXXX() does not transparently tell you that XXX is a property: it hides the intent of the author.

Fork/Join - jsr166y by William Smith

Does anyone know if Fork/Join - ("jsr166y") is expetced to make it?

Re: Fork/Join - jsr166y by Ismael Juma

William H,

The core fork/join framework will make it, but not the ParallelArray API. See:


Re: Additional Features by poplularity by Uffe Seerup

Operator overloading - REALLY Bad idea. Hurts code readability and was the primary cause for the destruction of SmallTalk back in the 90's. Why repeat the same mistakes like C# did?

Hmm. Would you like to elaborate on how this is a mistake in C#. It has been available in C# since day 0 (zero-based index) and I have still to encounter a single example of abuse of this feature.

Article spurs debate on Java Posse by Dio Synodinos

This article gets mentioned in Java Posse #225 and spurs a debate about the evolution of the platform. You can find it at about 16:00

Re: Additional Features by poplularity by Ricardo Mayerhofer

I don't think operator overload is a mistake. This would eliminate the need for syntax sugar in String and solves BigDecimal problem. These workarounds makes the languange inconsistent (why can I use plus operator in String and not in other objects?) and more complex.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

15 Discuss