I've recently started a poll to discuss the possibility of renaming the Fan programming language. The reason for a possible name change is simple - you can't google "Fan" and get hits about the language, and you never will (unlike Java).
If you're interested in this new language at all, please take the poll. We're also gathering alternative names, which you can leave in comments here if you prefer.
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.
The three votes in question were:
At Devoxx, the topics voted on were:
At JavaEdge and Online the features voted on were:
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):
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.
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.
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!
The most popular small language change request is better handling of nulls. As a result, I've updated my null-handling proposal.
The votes from Devoxx and JavaEdge were clear. Ordinary developers find handling nulls to be a pain and they would like to see language change to address it. At JavaEdge in particular almost a third of the first preferences and two thirds of the top four preferences went to null-handling.
I blogged my original thoughts two years ago. The updated null-default and null-safe invocation proposal is now available (v0.2).
The proposal covers two new operators, which follow Groovy for syntax (and thus consistency).
The null-default operator ?: returns the LHS unless that is null in which case it returns the RHS:
// today String str = getStringMayBeNull(); str = (str != null ? str : ""); // with null-default operator String str = getStringMayBeNull() ?: "";
The null-default operator also works particularly well with auto-unboxing.
Integer value = getIntegerMayBeNull(); int val = value ?: -1;
In fact, I hope that tools (IDEs and static analysis) would combine to effectively make the null-default operator mandatory when unsafe unboxing is occuring.
The null-safe operator ?. is an alternative form of method/field invocation. If the LHS is null, then the result of the whole method/field invocation is null:
// today
String result = null;
Foo foo = getFooMayBeNull();
if (foo != null) {
Bar bar = foo.getBarMayBeNull();
if (bar != null) {
result = bar.getResult();
}
}
// with null-safe operator
String result = getFooMayBeNull()?.getBarMayBeNull()?.getResult();
There is an interesting case if the last segment of the field/method expression returns a primitive. However, this can be handled by combining the two new operators (hence why its one proposal):
// today
int dotIndex = -1;
if (str != null) {
dotIndex = str.indexOf(".");
}
// with null-safe and null-default operators
int dotIndex = str?.indexOf(".") ?: -1;
I considered mandating this when a primitive occurs, but it would have undesirable side effects, so this is one best left to the tools to handle.
More details on all of this in the proposal.
Nulls remain a pain in Java. There simply isn't enough language support for this most common task. Every day, developers write logic to check and handle nulls and this obscures the meaning of the real code. And every day production systems go down due to NullPointerExceptions that weren't caught. This proposal provides a simple enhancement to Java that tackles the heart of the null issue.
Opinions welcome.
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.
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:
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.
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!
Once again, the great Devoxx conference allowed ordinary developers to express an opinion on the future of the Java language. This time, the focus was on prioritising which changes should happen.
The figures given below are of course indicative only. They are based on those Devoxx attendees who actually participated on the whiteboards. Also, the figures are as recorded at the end of Thursday (Friday scores not included). The whiteboard photos are available which provide additional information. Bear in mind that my figures may disagree with the photos in some small way based on when I counted the results relative to when the photos were taken.
This year, rather than simple "do you like this yes/no" questions, we posed something tougher. Prompted by Alex Buckley, we asked participants to rank eight language change proposals. Voters had to mark the number one against their highest priority, two against their next highest and so on until they had no more priorities. Attendees could also vote against a proposal by marking an 'X'.
The voting system was not the simplest, and we know a few people didn't vote correctly. However, we do believe that the vast majority did vote according to the rules making these results valid. The total number of voters was around 220, so the results have good validity.
| Feature | Properties | Multi catch | Null handling | List/Map syntax | Extension meths | Method pointers | Multiline Strs | Infer generics |
|---|---|---|---|---|---|---|---|---|
| 1 | 33 | 47 | 70 | 10 | 6 | 8 | 9 | 61 |
| 2 | 21 | 56 | 38 | 16 | 8 | 10 | 12 | 49 |
| 3 | 30 | 35 | 27 | 35 | 10 | 15 | 21 | 35 |
| 4 | 25 | 26 | 15 | 42 | 17 | 13 | 28 | 19 |
| 5 | 10 | 20 | 15 | 29 | 13 | 25 | 29 | 19 |
| 6 | 14 | 15 | 8 | 17 | 23 | 21 | 27 | 15 |
| 7 | 14 | 9 | 2 | 18 | 24 | 25 | 24 | 11 |
| 8 | 26 | 19 | 2 | 9 | 19 | 23 | 32 | 8 |
| X | 29 | 1 | 12 | 8 | 28 | 24 | 15 | 0 |
| Total Votes | 202 | 228 | 189 | 184 | 148 | 164 | 197 | 217 |
| Total votes (excluding X) |
173 | 227 | 177 | 176 | 120 | 140 | 182 | 217 |
| Weighted average | 4.08 | 3.41 | 2.49 | 4.32 | 5.36 | 5.25 | 5.16 | 3.07 |
Here are the first preference votes:
Adding the second preference votes:
Adding the third preference votes:
Adding the fourth preference votes:
Adding the remaining votes:
So, what do these results tell us?
Well, they are in fact amazingly clear. Null-handling was the first preference favourite by a small margin, ahead of Infering RHS generics and Multi-catch of exceptions. However, if particpants had been given just three votes, then these three would have scored almost exactly equal (135/145/138) and over double that of List/Map access (61).
Next in line (ignoring properties) was List/Map access using [], which can be seen by the big jump in third and fourth preference votes. Fifth was Mult-line strings, which developers seem to not be that fussed about.
Finally, extension methods and method pointers (method references) performed poorly in the vote.
Properties was shown to be the most divisive, with both a large number of votes for and against, and fewer in the middle preferences. For example, notice the high number of first preferences, but dropping back when adding second and third preferences. In addition, properties has a high number of low preferences and votes against (coloured black). Since properties isn't going to be included in JDK 7, the properties column is really just an interesting comparison data point.
Obviously in a free vote like this without any explanations, it is easy for people to not vote for items they don't understand. This could explain some the lower scores for Extension methods and Method references (see the total number of votes cast to confirm this). However, even taking this into account, these two don't seem to have as much support as the big three of Null-handling, Infering RHS generics and Multi-catch exceptions
It should also be noted that the graphs and the weighted averages are in line with one another.
In addition to the ranking above, there were some other votes.
The vote on closures was split 50/50:
| Yes | 41 |
| No | 41 |
The vote on abstract enums showed a majority in favour:
| Yes | 24 |
| No | 18 |
The vote on ARM (resource management) showed a large majority in favour:
| Yes | 64 |
| No | 11 |
The vote on some form of delegation showed a majority in favour:
| Yes | 36 |
| No | 9 |
The vote on for each over a string showed a majority in favour:
| Yes | 34 |
| No | 21 |
Firstly, a big thank you to the Devoxx voters, and to Stephan and the Devoxx organisers. I think this exercise was a huge success in participation. I'm certainly not in favour of language design by democracy, but I am very much in favour of gathering large scale information on what really causes developers pain. Clearly, handling nulls, RHS generics and catching exceptions are three big issues.
I hope to repeat the exercise again soon. And if any JUG (public or company internal) wants to do the same (maybe with different proposals) then I'd recommend it (and I've even got an Open Office presentation if you want some material - just drop me a line).
Any feedback or thoughts are welcome!
Devoxx 2008 is over :-( But is was a great conference again. And Java really started to feel alive again with real discussions of JDK 7.
In this post I'll go through the general discussions that were held on the Devoxx whiteboards. The figures given are of course indicative only. They are based on those Devoxx attendees who actually participated on the whiteboards. Also, the figures are a record taken at the end of Thursday (Friday scores not included).
The whiteboard photos are also available which provide additional information. Bear in mind that my figures may disagree with the photos in some small way based on when I counted the results relative to when the photos were taken.
Java FX had its big conference launch at Devoxx.
This question captured developers feelings about it:
| Yes | 62 |
| Maybe | 78 |
| Next version | 21 |
| Never | 45 |
| What is jfx? | 6 |
It seems clear that Devoxx attendees were pleasantly surprised by Java FX, and are thinking about using it.
Testing is an essential developer activity, but what tools get used?
I've broken out the big 3 unit testing tools here.
| JUnit3 | 54 |
| JUnit4 | 102 |
| TestNG | 23 |
| Selenium | 32 |
| None | 3 |
| Testing?! | 5 |
| EasyMock | 17 |
| JMock | 2 |
| HTMLUnit | 2 |
| Fitnesse | 3 |
| SOAPUI | 11 |
| Cobertura | 5 |
Obviously, a wide range of tools are in use, but in the unit test area JUnit still rules the roost.
A hot topic with many developers who still have to try and convince sceptical managers that REST is a valid solution.
I'm displaying the main numbers for the question here:
| REST | 50 |
| SOAP | 17 |
| Both | 30 |
| JSON | 6 |
So, developers prefer REST to SOAP. Somehow I'm not surprised!
A question that will always bring out strong opinions:
| Eclipse | 214 |
| Netbeans | 64 |
| IntelliJ | 126 |
| Vi/vim | 9 |
| Textmate | 6 |
| Jdeveloper | 5 |
| Notepad++ | 7 |
I'd have expected a stronger showing for Eclipse than this. Maybe Eclipse users have less strong opinions about their tool as Netbeans and IntelliJ users?
How up to date are the versions of Java we use?
The question asked Devoxx attendees to mark all they are using:
| 0.9b | 2 |
| 1.0 | 3 |
| 1.1b | 6 |
| 1.3 | 6 |
| 1.4 | 74 |
| 1.5 | 216 |
| 1.6 | 255 |
| 1.7 | 2 |
| 1.7 (patched) | 4 |
| 1.7 (closures) | 2 |
| Java ME | 13 |
So, more people are using Java 1.6 than Java 1.5. Interesting.
Checked exceptions are a feature essentially unique to Java. Many, like me, think they were a very bad idea.
But what about Devoxx attendees:
| Good idea | 34 |
| Bad idea | 36 |
| Both, It depends | 6 |
Opinion seems split on this topic. Although I should note that the number of votes was lower on this issue, so maybe there is an element of "don't care".
The JVM isn't only about Java now. What else are people using:
| Groovy | 49 |
| Scala | 30 |
| JRuby | 14 |
| Jython | 10 |
| Fan | 5 |
| PHP | 4 |
| Clojure | 5 |
| Don't care | 17 |
So, Groovy is looking pretty popular right now, with Scala seeing some good use. There is interest in additional languages too and this is healthy for the JVM's future (and personally, I was pleased to see Fan get 5 votes at this early stage in its life).
Thanks again to all the Devoxx voters. I'll write up about language change issues soon. Feel free to comment on any of the vote results.
Todays news that there are likely to be language changes in JDK 7 was a bit of a surprise. It seemed like the chance had passed.
Joe's post isn't very long, but it is clear.
I've used this blog, and previous visits to JavaPolis (now Devoxx) to discuss possible language changes. Some have been good ideas, others not so good. The main point was to provide a place for discussion.
The next phase after that was to implement some of the language changes. This has been achieved with the Kijaro project. As far as I'm concerned, anyone can write up an idea for a Java language change, and then I'll provide commit access at Kijaro for it to be implemented in javac - no questions asked.
So, before we all submit lots of crazy ideas and get carried away, lets remember that Sun provided some hints at JavaOne 2008. This presentation includes the following as ruled out:
And the following as 'under consideration':
The following are listed as 'long term areas of interest':
So, there is already quite a wide list on the table. Plus, there were other ideas suggested at last years JavaPolis, by both Josh and Neal:
In addition to all the above, I strongly suspect that there isn't going to be a chance to tackle problems with generics. This is similar to closures and properties. There isn't the timesclae or manpower to tackle these big issues in the timeframe being talked about (especially now Neal Gafter works for Microsoft).
Well, I'll mostly save those for another day. But I would like to see a proper consideration of enhancements to help with null handling. And enhancments to the for-each loop.
Finally, an appeal to Sun. Many in the community are deeply sceptical of any language changes at this point. The message should be simple - people need to feel that there is a clear means to vote or argue AGAINST a proposal, just as much as to make suggestions FOR change. Although I don't expect to make much use of the facility, I know there are many that do want to express this opinion.
This is a new departure for Sun in so openly asking for ideas from the community. We need to respond and reply with thoughtful ideas for what will and will not work.
