I'm on my way back from Javapolis 2006, unfortunately missing the third
day of the conference. One of the innovations this year was a bank of ten whiteboards where people brainstormed about the future of the Java language
and platform. I had a camera with me but I realized too late that I should
have taken snapshots of the contents of all those boards before I left. I hope
someone else will. The only snapshots I took were the vote tallies that I
discuss below.
There were three issues discussed on those boards that I'd like to share with you.
Closures
The first board contained a discussion of closures, including an informal
vote of people "in favor of" and "against" adding support
for closures. I gave a talk about closures yesterday afternoon, which explained
the goals and design criteria, showed how they fit quite smoothly into the
existing language and APIs, and more importantly explained in detail why
anonymous instance creation expressions do not solve the problems closures
were designed to solve. Before my talk about closures, the vote was about 55%
in favor and 45% against. After my talk the vote was 71% in favor and 29%
against. I don't think any "against" votes were added to the tally
after my talk. There was also a BOF (Birds-Of-a-Feather) session in
the evening discussing closures. Of the 20 or so attendees none admitted being against
adding closures. I'm sure the fact that the BOF was scheduled opposite a free
showing of Casino Royale didn't help, but I had hoped to hear from opponents more about their concerns. We discussed a number of issues and
concerns, most of which had been discussed on my blog at one time or another.
One issue that I discussed with a few individuals earlier and then at
the BOF was the idea of adding a statement whose purpose is to yield a
result from the surrounding closure, which you could use instead of or
in addition to providing a result as the last expression in the closure.
It turns out that adding this feature make closures no longer suitable
for expressing control abstractions. In other words, adding
this feature to the language would make closures less
useful! This is a very counterintuitive result. I first understood the
issue by analyzing the construct using Tennent's Correspondence Principle, but it is much easier for most people to
understand when the result is presented as specific examples that fail
to work as expected. For now I'll leave this as an exercise to the reader,
but I'll probably write more about it later. Incidentally, I believe the
folks who designed Groovy got closures wrong for exactly this reason.
There was a video made of my talk that will be posted to the Javapolis
website. Ted Neward also interviewed me on video, and Bill Venners
interviewed me on audio. As soon as these are available on the web
I'll blog pointers to them.
Native XML Support
Mark Reinhold gave a talk on adding native (i.e. language-level) support
for XML into Java. Though they were not presented as such, some
people prefer to think of the proposal as separable into a language
extension part and an API part. The
proposed APIs appear to be an improvement over the existing alternatives.
However, the language extension for writing XML literals appears to be only
marginally more convenient than the XML construction techniques provided by
libraries in JDOM. I personally
would like to see the new APIs pursued but XML creation provided in the
JDOM way. Mark took a vote by show of hands on how people felt about the two
issues, but I couldn't see the tally. There was also an informal tally about
adding native XML support on one of the whiteboards. The result was 29% in
favor and 71% against.
Constructor Invocation for Generics
Another much-discussed issue appeared on one of the whiteboards: the
verbosity of creating instances of generic types. This is typical:
Map<Pair<String,Integer>,Node> map = new HashMap<Pair<String,Integer>,Node>();
The problem here is that the type parameters have to be repeated twice.
One common "workaround" to this problem is to always create your
generic objects using static factories, but the language should not force
you to do that. A number of different syntax forms have been suggested for
fixing this:
var map = new HashMap<Pair<String,Integer>,Node>();
This unfortuately requires the addition of a new keyword. Another:
final map = new HashMap<Pair<String,Integer>,Node>();
This reuses an existing keyword, but at the same time it also makes the
variable final. Another variation on this idea:
map := new HashMap<Pair<String,Integer>,Node>();
In my opinion these three forms all suffer the same flaw: they place the type
parameters in the wrong place. Since the variable is to be used later in the
program, the programmer presumably wants control over its type and the reader wants the type to be clear from the variable declaration. In this case
you probably want the variable to be a Map and not a
HashMap. An idea that addresses my concern is:
Map<Pair<String,Integer>,Node> map = new HashMap();
Unfortunately, this is currently legal syntax that creates a raw
HashMap. I don't know if it is possible to change the meaning of
this construct without breaking backward compatibility. Another possibility:
Map<Pair<String,Integer>,Node> map = new HashMap<>();
You can see clearly by the presence of the empty angle brackets that the
type parameters have been omitted where the compiler is asked to infer them.
Of the alternatives, this is my favorite. I don't think it will be too hard to
implement in javac using the same techniques that work for static factories of
generic types.