A third vote on language changes has just completed, this time it was online. I'll summarise the results from the three votes in this post.
Three votes
The three votes in question were:
At Devoxx, the topics voted on were:
- Properties
- Multi-catch of exceptions
- Null handling
- List/Map access using []
- Extension methods
- Method pointers
- Multi line strings
- Infer generics on the RHS
At JavaEdge and Online 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
The later polls excluded properties as they are specifically excluded for Java 7. They also excluded extension methods and method pointers as these were the least popular options at Devoxx.
Here are the first preference votes for Devoxx, JavaEdge (ranked), JavaEdge, (not-ranked) and Online:
Considering the first to fourth preference votes (first at the bottom in dark green):
Totals
Unfortunately, we can't add the Devoxx figures directly to the rest as the data is incomplete. However, it is useful to add all JavaEdge and Online votes together:
So, what do these results tell us? As always, absolute answers are difficult, because not all voters followed the same rules (online voters clearly didn't rank properly), and Devoxx was asked a different question. However, some things can be established, based not only on total votes but also how the preferences went from 1 to 10.
- Devoxx voters favoured Infer-generics, Multi-catch and Null-handling.
- JavaEdge voters favoured Null-handling, String-switch and Multi-catch.
- Online voters favoured Multi-catch, Null-handling, Infer-generics and String-switch.
So, these four options polled consistently highly in each of the different votes (except Infer-generics which did badly at JavaEdge). This now lends quite significant weight to the question of 'what does the community want' and 'what pain points need addressing'. The small language changes for Java 7 project now has some solid data to work from.
My take is that Multi-catch looks like a strong favourite for inclusion, as does String-switch. Infer-generics had a slightly more mixed reception in JavaEdge, but is popular elsewhere.
The big question is over Null-handling. Three separate votes has ranked it highly, with it taking the highest number of first preference votes in three of the four measured graphs above. There is a clear desire for change and a clear proposal. I hope the opportunity is not missed.
Summary
As more votes stack up, the statistics become more secure. We can now say that out of the ten polled items, the top four are Null-handling, Multi-catch, String-switch and Infer-generics.
Any feedback or thoughts are welcome!
Null handling is bad 'cause it encourages applications to sweep nulls under the rug rather than dealing with 'em. Instead, applications should use JSR-305 annotations like @NotNull to prevent null creep.
ReplyDeletehttp://code.google.com/p/jsr-305/
Such argument is just a bugbear theory. In contrast the reality is huge amount of code like 'expression == null ? null/default : expression'.
DeleteI would give adult users freedom of choice and help rather then restrictions and complications.
Thx for help!
Hi!
ReplyDeleteIn my opinion votes should be split in:
- The problem:
--I have problem with that.
--It's problem but I don't mind to keep things unchanged.
--It's not problem for me.
-Suggested solution:
--I like this proposal.
--No opinion
--I this this proposal is not good enough.
-Other solution
--I think suggested one is good.
--No opinion
--I think better solution should be searched.
That would help to obtain more competent opinions. Than [Yes 100% , Yes 50% , No ] voting.
Greetings.
Jesse, while I support null-handling in the type system (of which @NotNull is a very weak form) I cannot accept that it removes the need for null-handling operators.
ReplyDeleteThe ?: operator is needed just to handle auto-unboxing properly, as well as numerous other cases where defaulting a null-value becomes necessary. The ?. operator is a pragmatic response to the fact that nulls are already here, causing pain and not going away. Handling nulls today requires so much code that the true business logic of methods gets lost.
It wouldn't be appropriate to make ?: mandatory because the programmer may know it is safe, but the compiler doesn't due to the lack of @NotNull or similar. While we can add appropriate @NotNull declarations to our own code, we may not be able to add it to other code that we use.
ReplyDeleteI remember the pain when 'const' was added to C++ and it took years for it to appear in library declarations.
I wander why people are so determined for null-checking.
ReplyDeleteI admit it was problem for me, but I simply added template:
ifnull
if (==null){throw new NullPointerException(.class.getSimpleName());}
Since then I do not see this as big problem.
Other thing is to handle that in JavaDocs....
All these votes and graphs make a fun read and a fun discussion. But nobody really believes they are meaningful, right? I'm not sure the sample of "conference attendees motivated enough to answer a survey or stand at a whiteboard or vote in an online poll" is meaningful. It's a fun way to shape and guide the discussion but is Sun going to use this data for something?
ReplyDeleteNobody cares about getting decimal literal type? That's surprising and disappointing considering how often this is used and how relatively easy and isolated it would be to burn this into the compiler (compared to much of the other stuff).
ReplyDelete@Casper Bang
ReplyDeleteI think for that purpose there should be sub-language. Or at leas liblary.
Mark, I'm not suggesting that the ?: should be mandatory.
ReplyDeleteLasu, I think you're missing the point of handling null. Adding an Eclipse template aids the writing of code, but it doesn't help reading it.
Hamlet, You might choose to interpret this as irrelevant, but it was requested by key people in Sun, and to be done in this way. I also think that the results speak volumes, as they are pretty consistent across multiple different sources.
Casper, Relatively speaking, few developers use BigDecimal. Of course, this is partly a chicken and egg thing, as its so hard to create one...
@Stephen
ReplyDeleteI didn't considered this as reading problem while JavaDoc is far behind current Java as i already said:
http://lasu2string.blogspot.com/2008/12/is-javadoc-killing-program-evolution.html
But in destination it would be nice to see support for null-checking and other validators … but I like it only if that would be supported by both: Java and JavaDoc.
Some of you may want consider sample String-switch workarounds:
ReplyDeletehttp://lasu2string.blogspot.com/2009/02/using-strings-and-objects-in-switch.html
My very small language change wish:
ReplyDeletenot throwing a NPE with a null Iterable when using the enhanced for loop
Stephen: Although public polling is among the worst possible methods of language design, your untiring efforts in digesting these statistics has produced an interesting demonstration of the effect of author bias. I wish the Java community had someone with the same level of commitment to complete the jsr310 Date and Time implementation for Java SE 7.
ReplyDeleteNeal, At no stage have I said that voting on language changes should be decisive, however it is a very useful way to gather feedback on what is, and is not, causing pain to developers.
ReplyDeleteFor example, list/map access using array syntax was consistently lowly ranked, yet it is being seriously considered for Java 7. This voting exercise means that Sun needs to explain very clearly now as to why a lowly ranked/disliked proposal such as that should be included.
I find your comment on bias, however, pretty objectionable. The raw data is available for each vote, and the graphs are no more than a visual view of the data. Yes, I have added a small amount of commentary, but anyone looking at the graphs would come to the same conclusion - I've not made anything up here.
Now, it so happens that I believe the number of problems seen in production from NPEs is clear evidence of the need for better null handling in Java. The votes clearly and unambiguously show that many other developers feel the same pain (almost 50% of voters at JavaEdge placed null-handling in their top two of out of ten choices). I've been pro-active and proposed a solution. If you don't like it, then don't just whine - propose an alternative (or explain why we should all carry on putting up with NPEs in production).