I'm really surprised, that over 200 fellow developers participated! Thanks to everyone for voting!
Now let's check out the results. First of all I gave you the choice to let me know how you found this poll.
There were 80 votes submitted through my blog and about 50% of all submissions came through various other channels like DZone or Alex Miller's Java 7 blog. I'm a little disappointed about the participation of our JUG. Only 22 people voted, although there are about 173 members signed up in our Google Group.
Unfortunately about 10% of the votes are invalid. Maybe I should have put the instructions on the blog post directly instead of using Stephen's presentation. However, there are 181 correct votes and those are used in the following charts:
1. Map for-each
2. For-each iteration control
3. List / Map access
4. Infer generics in declarations
5. Multi-catch of Exceptions
6. String Switch
7. String interpolation
8. Multi-line Strings
9. Resource Management
10. Null-handling
It looks like most people wanna see an improved Null handling (change no 10) in the coming Java 7 release. The improved List/Map access (change no 3) on the other hand is something that almost all the correct voters oppose. If you are interested in the cleansed results, I published as a separate website.
I thought a lot about how I should interpret these votes. Frankly, I'm a little surprised about the results. I didn't think that so many fellow developers would like to see an improved Null handling. However, the votes at Devoxx indicated the same and I do admit Null handling can be a huge PITA. What I am kind of shocked about is the huge resistance to closures-related features like resource management (change no 9) or Map for-each (change no 1). Maybe this indicates that a lot of developers are not yet ready for closures in Java. After all, it might have been a reasonable decision of Sun to drop closures - for now.
So, what am I gonna do with those votes? Well, I'll email them to Joe Darcy and hope Sun will include your votes into their decision-making process. I know these votes only speak for a very small fraction of the Java community, but I think every vote counts.
Thanks again everyone for voting!
9 comments:
"I hope Sun will include your votes into their decision-making process"
I hope one day Java will be really free and open without being dependent from "their decision process". Javaland ist just like Microsoftland where everything is decided by "their decision process".
The graphs are great, but it's hard to really get a feel for the votes against a proposal. Can you make those votes negative to that the bars go in two directions? Can you post the raw data?
Improved null handling as I have seen it proposed would be nice, but not an earth shaking change. Plus, you can use it or not as you please (that is probably true of many of the changes?).
I liked the recent article I saw on adding 'properties' to Java - but I hear it won't make it into J7.
"What I am kind of shocked about is the huge resistance to closures-related features like resource management (change no 9) or Map for-each (change no 1). Maybe this indicates that a lot of developers are not yet ready for closures in Java."
Let me first state that I would love to see closures in Java. Second, I also would have voted against these two changes (map-foreach and resource management). Why? Because in my opinion those two constructs don't deserve a language change on their own. They could be implemented as library, if we had closures in Java. I want closures, such that I can implement these and similar constructs my own; or use a library which provides them. Having them as native language constructs is not neccessary and a waste of ressources.
As Fatih mentions, I believe that the resistance to the for-each and using options is based around a desire for closures rather than opposition, and I suspect that is particular to this online audience.
As a co-author of FCM/JCA closures I should view this as a good thing, but I don't. I have become more and more sceptical over time that Java and library defined control statements go together.
aberrant > Can you make those votes negative to that the bars go in two directions? Can you post the raw data?
You can find the raw data here. Send me a link if you published your own graphs.
Developer Dude > Improved null handling as I have seen it proposed would be nice, but not an earth shaking change. Plus, you can use it or not as you please (that is probably true of many of the changes?).
I guess it's not about the choice of using it or not using it. It's more of a "tackle the problem in different ways angst". If you have multiple ways of doing things your code is not uniform anymore. A lot of people believe their way of coding is the way to go and would get pretty upset if they need to look at code that doesn't comply with their style.
Fatih Coşkun > I also would have voted against these two changes (map-foreach and resource management). Why? Because in my opinion those two constructs don't deserve a language change on their own.
JodaStephen > I believe that the resistance to the for-each and using options is based around a desire for closures rather than opposition
You are probably right. I haven't thought it that way and it's only reasonable to vote against these proposed changes if you wanna do it right - with closures.
Hi
I think votes construction is bad (results are hard to interpret).
I would suggest:
1. I would like to see that solution.
2. I found this as problem for me, but I do not have clear opinion about suggested solution.
3. Have no opinion.
4. Do not found this as problem.
5. Problem is real but suggested solution is not the best one.
6. Do not like this suggestion.
7. I use other solution without any problems, so i do not need it.
I already wandered about string-switch:
http://lasu2string.blogspot.com/2008/12/string-switch-small-language-changes-on.html
Greetings!
At Devoxx I voted for resource management and I would have voted for map-for-each (can't actually remember if it was on there or not), but in retrospect I should have voted against them for exactly the reasons that Fatih mentionend. I'd love to have both features in the language, but changing the language just does not feel right to me anymore given that closures would render it completely obsolete.
- Martin
I think we have our initial set of proposal! Check out Joseph Darcy's blog!
Post a Comment