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.

Nimbus

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?

JSF 2.0 (JSR-314)

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):

• Component authoring is too hard
• Component kit producers had to invent mechanisms for resource loading, AJAX, that sometimes conflict with each other
• Configuration is way too tedious and dispersed over too many artifacts
• The need to frequently redeploy, and the “stack trace from hell” are productivity killers

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 :-)

Blue-Collar Types

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.

Closures

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:

• To properly do a control structure where a variable can be either one of the 8 primitive types or a reference type, one would need to declare 9 variants. Make that 81 variants if two variables are involved. Or somehow throw more autoboxing at the problem. I agree this is nasty. I sure wish Java didn't have those 8 primitive types.
• Non-local return is bound to be confusing. I agree. The trouble is that there are two use cases: the “snippet of code” use case and the “control structure” use case, where Java programmers have opposing intuition what return means. I still hope that this can be salvaged. Perhaps by outlawing return outside control invocations, but Neil Gafter doesn't like that.
• Capturing a non-local variable can be surprising. Josh had an unpleasant example where a closure captures a for loop index. I can see how this would be baffling to a programmer who is unaccustomed to closures, i.e. most Java programmers.
• There is no way to implement the Java 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.

Scala

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.