For the past few days I have been in the fabulous country of Israel at the JavaEdge conference. Duing the keynote speech, I presented 10 possible language changes for JDK7, and asked the audience to vote on them.
These results are in more depth than the Devoxx figures simply because we could extract information about each persons preferences. For academics or statisticians the raw data is available in Open Office format.
Given ten language changes, rank them according to priority
So, the question is the same basic question as we asked at Devoxx, but with a different selection of changes to pick from. The results show that 171 people voted correctly (starting from 1 for the first preference, 2 for the second and so on). Another 41 attendees voted mostly corrrectly, skipping one of the prefereces (for example marking a 1st, 2nd, 3rd and 5th preference, but not a 4th). A final 113 attendees didn't follow the instructions at all, and marked multipe 1st preferences, multiple 2nd preferences and so on.
The features voted on were:
- For-each loop over a Map
- Control over for-each loops (index/remove)
- List/Map access using []
- Infer generics on the RHS
- Multi-catch of exceptions
- String switch
- String interpolation
- Multi line strings
- Resource management
- Null handling
These results are for those who completed the voting according to the rules (171 attendees).
Here are the first preference votes:
Adding the second preference votes:
Adding the third preference votes:
Adding the fourth preference votes:
Adding the fifth preference votes:
Adding the remaining votes (white is didn't vote, black is 'this is a bad idea':
Now those that almost voted according to the rules - votes are adjusted to move everything beyond the missing column up (41 attendees).
All votes:
Now those that voted based on general preference (103 attendees).
All votes:
So, what do these results tell us? (I'm focussing the analysis on those who voted fully according to the rules, as it is hard to interpret the results from those who simply gave arbitrary rankings).
As with the Devoxx results, 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.
The other 144 votes that were not completely according to the rules are harder to interpret. If someone wants to give it a go, feel free to interpret the raw data.
Summary
Firstly, a big thank you to the JavaEdge voters, and to the AlphaCSP team in Israel. Again, we have some really interesting figures from this vote, with null handling again coming out top. Clearly, there needs to be some real thought about whether some form of null handling can be achieved.
Any feedback or thoughts are welcome!
Hi Stephen I really hope some changes make it, but it feels like we're discussing changes for too long now and that Java 7 isn't going to get much features anyway. I think I would appreciate most of these proposals, and even more so closures and properties.
ReplyDeleteI imagine that there are no people who would comment here and not like to see closures or properties in java.
ReplyDeleteAmong the changes above I like the null-handling most, and dislike the ones most which could be implemented as API if closures were there (i.e. ARM and enhanced loops).
Great work, Stephen! Thanks!
ReplyDeleteHowever, it unfortunately escapes me why null-handling is so popular. I totally agree with Charles Nutter on this matter. Furthermore, I just don't see any real use case for this ... yet. I mean if you have something like 'Object d = a.?b.?c;' to forego your null-checking then I assume that d is assigned null if any call on the RHS returns null. That'd mean that null is a valid value for some operation on the RHS. That, in my opinion, should rarely be the case or at least dealt with explicitly rather than hiding it in syntax. Furthermore, now you have to deal with d potentially being null. Well, it all seems a bit strange and error-prone to me; not to forget, as Charles mentions, the "problem" you'd have with assignments to primitve types. But if someone comes up with some compelling use cases, I'll reconsider my position ;)
Cheers, Martin
I agree. Null-handling strikes me as one of the worst features to add to the language. Adding compile-time checking for nullability is one thing, adding a null-handling operation is another. I am strongly against the latter.
ReplyDeleteO reified generics, where art thou ?
ReplyDeleteThis is one of the top priority to remove tons of boiler plate codes (think JAX-WS/B/..., think JSF/EL, think Swing/JavaFX data binding ...).
We do need reified generics with good genericity access to it !
Stephen: We really appreciate that you have the passion and, critically, free time to gather and digest this kind of information for the Java community. I wish we had someone with your passion and free time to complete the Java Time API (JSR 310) for SE 7. Alas, we each have to set priorities.
ReplyDeleteI see where you guys are coming from. Theoretically it would be better not have a null value at all. Unfortunately we have it, and we have to deal with it.
ReplyDeleteIn my projects I always try not to produce null values, I procude empty lists or other null-pattern-objects. But what about co-coders? The bigger the project, the likely it is that I will encounter a null value where there should not be one.
Consider the following example:
User user = userManager.getUser(userName);
if (user == null) return;
History history = user.getHistory();
if (history == null) return;
history.print(out);
Again, I know, it is bad that there are potential null values here, but I have to deal with it.
The following code is much more readable and does not loose any information in this case:
History history = userManager.getUser(userName).?getHistory();
if (history == null) return;
history.print(out);
Hello!
ReplyDeleteI will describe my opinion about this changes.
String switch:
http://lasu2string.blogspot.com/2008/12/string-switch-small-language-changes-on.html
Hope u will give yours opinion as well.
Greeting!
Null handling:
ReplyDeletehttp://lasu2string.blogspot.com/2008/12/null-handling-small-language-changes-on.html
For-each loop:
http://lasu2string.blogspot.com/2008/12/for-each-loop-small-language-changes-on.html