My day 3 at Java One ranged from the Nimbus UI and the future of JSF to interesting discussions about closures and Scala. Details below.
The presentation on the Nimbus look and feel
was packed. Nimbus is a pretty L&F, and it will be the standard for Java
FX. Everything is vector-drawn, so it will scale nicely to high-resolution
displays. (Check out this nifty sampler.) I would like to tweak the
colors a bit, perhaps make the nimbusSelection
less green. In a
Java program, or in a L&F JAR, I can do that by calling
UIManager.put("nimbusSelection", new Color(...))
. I asked what
the story for end-user tweaking was, and was told that I'd have to edit
swing.properties
. Ok, but how do I specify a color?
The JavaServer Faces 2.0 presentation was also packed. Ed Burns and Roger Kitain listed some of the pain points (which I amplify a bit):
JSF 2.0 will be based on facelets, which should really help with error messages.
There were demos of a page description language and the ability to author components using Groovy (see also this blog), and also some AJAX stuff that went over my head.
There was no information about how configuration will look like. Hopefully, we'll get a Seam-like navigation option and annotations for managed beans. Or better, Web beans. I asked Ed about the strategy for Seam-like Web beans, but it all seems still very much in the planning stage. It is all supposed to be done by Java One 2009, so hopefully things will get moving soon :-)
When discussing the complexities of
wildcards and closures, the issue of types kept coming up. I really like
compile-time typing. It enables the compiler to catch stupid mistakes, and it
enables the IDE to do auto-completion. Of course, there is a tradeoff: I
can't share code like the duck-typers do. For example, no
max(x, y) { return x < y ? x : y }
But I don't want to catch everything at compile time if the cost is too
high. For example, C++ checks for const
at compile-time. It is a
pain in the rear, and Java wisely decided not to do that. I am not sure that
the various experiments with compile-time checks against unintended null
pointers are worth the trouble. I am not even sure that checked exceptions
are so great. In particular, I am mightily tired of propagating the
InterruptedException
.
I find that Java arrays (with covariance and the array store exception) are a reasonable compromise. A number of people who feel strongly about this gasped when I expressed that sentiment, admonishing me that this is unsound. Well, life is unsound.
Every language makes tradeoffs between compile time and run time checking.
I think with generics, we may have tried to check too much at compile-time.
Consider this
blog by Alex Buckley where he explains why we can't have a generic
new T()
. The type system cannot ensure that there is a no-arg
constructor. Ok, but that doesn't mean that we can't have the feature. One
could make a run time check. My feeling is that the type system should be my
servant, not my master.
Martin Odersky and I chatted about the wildcard syntax and the history of
generics. He said that the Sun folks approached the introduction of generics
very cautiously because they did not want to repeat the disaster of inner
classes! At the time, inner classes were perceived to be a short-sighted
reaction to C# delegates, with ugly syntax and initially underspecified
semantics. Indeed, it took many years for the generics proposal to mature.
Wildcards were literally tossed in at the last minute. (The ? super
T
syntax was suggested at Java One, shortly before the Java 5 release,
by someone in the audience of Gilad Bracha's presentation, to replace the
proposed T extends ?
,)
Now, of course, we have people urging caution with closures so that we don't repeat the disaster of generics.
Alex Buckley told me that he asked in the “future language features” BOF how many people wanted closures. Lots of people, more than half the room, raised their hands. How many wanted BGGA? Maybe 6. CICE? Maybe 6. FCM? Maybe 5.
I ran into Josh Bloch, and he walked me through a presentation about some nasty aspects of BGGA closures. Among them:
return
means. I still hope that this
can be salvaged. Perhaps by outlawing return
outside control
invocations, but Neil Gafter doesn't like that.for
loop
index. I can see how this would be baffling to a programmer who is
unaccustomed to closures, i.e. most Java programmers. for
loop with BGGA
syntax. For example, you couldn't do myFor(int i = 0, j = 0;
...)
. True enough, but it doesn't bother me. I'd still like
with
, withLock
, doLater
, even if
they don't have 100% the same syntax as for
.Josh doesn't think that there is much in terms of the “etc.” Is a handful of control structures worth the considerable hassle? I still prefer closures over inner classes, and I am holding out some hope that a clearer syntax will emerge.
If the Java language is
increasingly resistant to large-scale evolution, what is a programmer to do?
Is it time to plan the escape from the Java prison? Like so many other
people, I have been looking at Scala. Martin Odersky has given his
Scala talk again, and it seemed quite a bit more convincing than last year.
Maybe because the Scala syntax looks much more familiar after I had used it a
bit. Maybe because I now believe his claim that a typical Scala program uses
half the lines of code as the equivalent Java program, because that is
exactly what happened to me. It is so liberating to do without all that
boilerplate that you have in Java.
Clearly, Scala is not a blue-collar language, and I cannot see every Java programmer flocking to it. But I would like to get more experience working with a project that mixes Scala and Java. Preferably with IDE support. There is an Eclipse plugin that is “getting better”, and just recently Caoyuan Deng has made amazing progress with a Netbeans plugin. Adam Bien relates this story:
During a meeting in the Community Corner (java.net booth) with James Gosling, a participant asked an interesting question: "Which Programming Language would you use *now* on top of JVM, except Java?". The answer was surprisingly fast and very clear: - Scala.