The latest two polls ask developers about the Java language enhancements that are part of Java 7 (the Java SE 7 Developer Preview is available for download now; the formal release will come in just a few months). Last week's poll asked What's the most important Java 7 enhancement for the work you do? The majority voted for Project Coin (JSR 334). As a result, the current poll follows up on that theme, asking Which Project Coin (JSR 334) Java language enhancement will be most useful? Voting will be open only until Monday, so now is the time to vote if you haven't already.

58 votes were cast in last week's poll, and two comments were posted. Here are the results:

What's the most important Java 7 enhancement for the work you do?

  • 60% (35 votes) - Project Coin (JSR 334)
  • 14% (8 votes) - InvokeDynamic (JSR 292)
  • 9% (5 votes) - Lightweight Fork/Join Framework (JSR 166y)
  • 9% (5 votes) - More New I/O (JSR 203)
  • 5% (3 votes) - A different Java 7 enhancement
  • 3% (2 votes) - I don't know
  • 0% (0 votes) - Other

The result is pretty clear cut -- though the sample size (58 total votes) is pretty small. Nonetheless, I think the clear majority voting for Project Coin is a testament to the careful selection of upgrades that are actually implemented within Project Coin. The community is saying that, right off, the Project Coin enhancements will be useful for the work they do every day.

This view is backed up by prunge's comment:

I picked coin because I'll use it more in day-to-day tasks than the other features. But the NIO filesystem additions will actually allow me to do things in Java that I couldn't do before without native code/hacks.

osbald expressed a different view:

Voted different as I'd be most interested in the odd speed tweaks that've gone into the v7 JVM ..oh and its basis on OpenJDK. InvokeDynamic I might use indirectly via Groovy/JRuby but in my daily coding rotines? can't see myself using it. Small coin dosent exactly trill me either, for the most part the syntax 'enhancements' don't seem worth sacrificing backwards compatibility with Java 6.

Having been around the world of code for a few decades, I can certainly see osbald's point in questioning the wisdom of losing backward compatibility. I mean -- in my view, Java is becoming akin to historic languages like COBOL, Fortran, and C, in terms of its installed, completely-validated code base. I spoke with a developer last night who works on business applications that are based on COBOL accounting code written decades ago. Now, no one's developing big new apps in COBOL today (I thinkthat's a true statement, anyway). So, in that way, Java's entirely different.

But, if you look at Fortran, and especially C -- new code is still being written in those languages. I think it's quite possible that 30 years from now, code written in COBOL, Fortran, C, and Java that hasn't been edited for decades will still be running within many operational environments.

It's a difficult decision -- Java is young enough that you want it to grow such that it remains competitive with newer languages; yet, at the same time, the installed base of Java code is already enormous, despite the language's relative (to COBOL, Fortran, C, for example) youth. So, you need to be very careful not to "break" the old installed code base.

Anyway -- the current poll is about Project Coin itself (which specific enhancement is most useful?); voting ends on Monday. Weblogs

Since my last blog post, quite a few people have posted significant blogs on

Java News

Here are the news stories we're currently featuring in our Java news section.

Tori Wieldt reports on TheServerSide Java Symposium panel discussion, The Java Community Process: What's Broken and How to Fix It-

In a panel discussion today at TheServerSide Java Symposium, Patrick Curran, Head of the Java Community Process, James Gosling, and ?Reza Rahman, member, Java EE 6 and EJB 3.1 expert groups, discussed the state of the JCP. Moderated by Cameron McKenzie, Editor of, they discussed what's wrong with JCP and ways to fix it...

Shai Almog's latest LWUIT post is Constantly Theme'd:

One of the often requested features in LWUIT's themes has been the addition of constants for themes. Constants allow the theme designer to "hint" of desired functionality to the application code, e.g. a particular theme might have a constant indicating that it wants the scrollbar to fadeout when unused. The LWUIT resource editor now includes an additional tab for creating such constants...

The Brussels JUG presents Leo Exter's Bootstrapping: Probably the most important term a startup entrepreneur should know -

To my surprise, a lot of startups I come across aren