Slightly more than half of respondants to last week's java.net poll believe that closures will improve Java. A total of 365 votes were cast. The exact poll question and results were:
What do you think about closures in JDK 7?
51% (185 votes) - Closures will improve Java
12% (44 votes) - I was/am opposed to closures in Java
14% (50 votes) - Where was the community process in this decision?
9% (32 votes) - I don't know
13% (46 votes) - What's a closure?
2% (8 votes) - Other
While this is not a scientific poll, the results clearly show that, among those who chose to vote, closures in Java are viewed positively by a majority of developers who understand what closures are.
Unsurprisingly (to me), a significant number of people chose to register complaint on how the decision to include closures in Java 7 came about. "Where was the community process in this decision?" is a question that was asked by dozens of commentators immediately after Mark Reinhold's surprise announcement at Devoxx that closures (of a certain type) will be included in Java 7. While we can't tell for sure, my guess is that more of the people who selected this option oppose closures in Java -- but, I also think that this option was probably selected by many people who might favor the inclusion of closures in Java, but object to the effective closure of debate on closures in Java 7 that occurred a year ago, only to be followed by a sudden announcement out of the blue that closures will be included and Java 7, and "here's the type of closure we're going to include." That seemed rather dictatorial to me.
In his comment posted to the poll, ipsi said:
I'm a little concerned about the community process in this decision... I haven't seen the actual announcement (is that visible online anywhere? Or at the least the actual wording?), but it sounds like the announcement was "There will be closures in JDK 7". Not "Well, we've decided to push back the JDK 7 release for reasons that have nothing to do with the Sun/Oracle Deal, and now have time to revisit the closure proposals", not "Project leadership has changed, and we're interested in revisiting closures", but "Closures are coming. Our closures. Applaud. Now".
It's true that a few days ago, in his post "There's not a moment to lose!", Mark Reinhold invited the community to participate going forward:
Revising a programming language that’s in active use by millions of developers is no small task. Sun neither can nor should do it alone, so I hereby invite everyone who participated in the earlier closures conversations--as well as anyone else with an informed opinion--to join us.
But, clearly, in the past year, thought was being put into having some form of closures in Java 7 -- yet, that thinking was not occuring within the broader public venue. Hence, the astonishment by virtually all observers when Mark's "Closures: It's time to add them to Java" slide appeared on the big screen at Devoxx. As Alex Miller said in "Closures after all?":
I can't say what to make of that really. For years Sun has been saying that there is no consensus on closures and delayed the formation of a JSR or expert group on the subject despite having three proposals, all with prototypes.
dog registered another concern in his poll comment:
The only thing that worries me is this "keep up with the Joneses attitude" that if language X has it Java must have it too. I like Java, I still think it is a great language and is better than many alternatives (including C# and Scala). But Java shouldn't be dynamically typed or have automatic type inference (like OCaml) or have some of the weirder features other languages have.
To me, yet another surprise is Mark Reinhold's declaration that the reason closures are needed now (the reason "there's not a moment to lose") is the advent of multicore processors! Are multicore processors so new and novel?
New poll: Java's parallel programming support
This week's new java.net poll proceeds from this line of thought. What do you think: Is Java's parallel programming support sufficient to meet 'the Multicore Challenge'? If not, will closures in Java 7 eliminate the deficiencies?
I'm working on an article for NetBeans Zone about how the satellite software provider Amphinicy Technologies is working with SES-Astra TechCom (who own the applications) in creating applications on the NetBeans Platform. They have around 10 applications built on the NetBeans Platform, but the story discusses 5 of these (since the others are confidential for various reasons). Here's a quick sneak preview on each of these (detailed descriptions and more [and larger] screenshots in the upcoming article) ...
It's been a
So, last week I bought a couple of books, a train ticket, and headed south to Antwerp. At this time of year, the sky over Antwerp in Belgium has the same kind of shade of post-apocalyptic sci-fi gray like the sky over Hamburg in Germany, so I didn't go there for a boost of my vitamin D levels. Instead, I went there to spend a few days in a cinema complex, with very comfortable chairs, interesting talks and curious Java developers - the yearly Devoxx conference. As I didn't have a presentation scheduled myself, I could sit back and enjoy the sessions. On the first day of Devoxx, I saw Mark Reinhold's fun JDK 7 talk, with the simple closures moment, which a few hours later led to a packed JDK 7 BoF. Squeezed between the two was Joe Darcy's nice presentation on the small language changes in Project Coin. I saw James Gosling's session as well, which had an entertaining run through the complexities of dealing with legal & tax codes on the world...
On thursday 12th november, I attended to the Atmosphere evening of the Paris JUG. News from Paris JUG: * Paris JUG is at devoxx09 that week. * For the second birthday of Paris JUG, the theme will be the open source in France. We are searching for a cheap room that can contain from 250 to 300 persons. Atmosphere presentation: Jean-Francois Arcand has presented Atmosphere, a portable and open source framework to do ajax push or Comet (which process ajax push requests in a non blocking way)...
When I comment in mailing lists that I am implementing a
registration module for my application, hundreds of other developers
comment they are coding exactly the same functionality in their projects
- an indicator that something is missing in the Java EE Universe. Registration is just an example, there are many others like
notification, content repository management, etc. If you look for
solutions to such problems you will find a lot of frameworks and
products supplying solutions for separated parts of a common enterprise
application. The point is, you can't can adopt one of this features
without adopting the whole framework surrounding the feature and usually
you can't or you dont'n want to do that. It is senseless to expect such
specialized features included in the container specification, but at same time we
should recognize that today it takes too long from the concept of a
feature to production in a standard Java EE Server, and it is not a
problem of the server, it is something else, something missing...
While speaking at the Globalcode Developer's
conference in Rio de Janeiro, I met a dynamic and intelligent
student by the name of Thiago
Diogo. Thiaogo presented his group's work on student project to
provide a real, mission critical distributed application for his
university, Universidade Federal
Fulminense. They chose JSF 1.2 and Seam as a part of their stack. One idea Thiaogo shared with me was a memcached JSF component...
I authored a new refcard covering GlassFish v3, This is different from my previous one which covers GlassFish v2. This new refcard discuss the following items ...
In the Forums, skja gets an error Initializing Mojarra 2.0.1 (FCS b02) Error: java.lang.IllegalArgumentExcept: "I am using Mojarra 2.0.1 (FCS b02) implementation of JSF. I am using Netbeans IDE 6.7.1, Java 1.5.0_16 & same jre; on a Windows XP machine. I have GlassFish 2.x server. I am trying out the project in this url ..."
technolgia wonders if there is a Calendar setDate Bug?: "Hi, When i display the calendar component i want the date displayed to be the current date.I tried the setDate(new Date()) but the date selected is not the current date. Is this a bug? Kindly help me with this. Thanking you ..."
ungsikyu has Custom TableCellRenderer questions: "I would like to show a Map> as a table using JXTable. I want to show a key in a column and corresponding values next to the column. I also want to enable individual value selection and hyperlinking. I tried..."
In our current Spotlight, Terrence Barr invites us to Check out Java Card 3.0 Connected Edition: Real Java, just really flat ;-): "Java Card 3.0 was released a couple of months ago – and the second update (version 3.0.2) is scheduled for December. If you haven’t paid much attention to Java on smart cards because you thought it’s not “real” Java – well, look again. It’s true that Java Card 2 was very limited in many ways – a testament to the kind of technology you had available on smart cards 10 years ago. There are billions of these out there today..."
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
