Skip to main content

Java One Day 3

Posted by cayhorstmann on May 8, 2008 at 10:57 PM PDT

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 href="https://nimbus.dev.java.net/spec/index.html">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 href="https://laffy.dev.java.net/">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?

src="http://nimbus.dev.java.net/spec/images/JTable-Example.png" />

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 src="http://weblogs.java.net/blog/cayhorstmann/archive/2006-09-08/hell.png"
    style="float: right; margin-left: 1em;" />

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

src="http://weblogs.java.net/blog/cayhorstmann/archive/blue-collar.jpeg"
style="float: right; margin-left: 1em;" />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 href="http://blogs.sun.com/abuckley/en_US/entry/new_t_is_not_possible">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? He makes a strong case that the hassle is considerable. I still
prefer closures over inner classes, and I am holding out some hope that a
clearer syntax will emerge.

Scala

style="float: right; margin-left: 1em;" />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 href="http://www.scala-lang.org/">Scala. Martin Odersky has given his
Scala talk again. I liked the talk much better this year than last.
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 href="http://blogtrader.net/page/dcaoyuan/entry/scala_for_netbeans_screenshot_11">amazing
progress with a Netbeans plugin. href="http://www.adam-bien.com/roller/abien/entry/java_net_javaone_which_programming">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.

Related Topics >>

Comments

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

Good morning, Cay. I'm on the JSF 2 EG, fwiw, so I'd like to touch on this a bit. The current state of the JSF 2 spec covers two things: easy component development (ezcomp), and Ajax, which you saw demoed at the TS.

We have talked about configuration some, but haven't actually implemented anything yet, as our focus was on the two items above for the EDR which we had hoped to have out for JavaOne. It's currently being held up for some seemingly (to me :) trivial reasons, but Ed and (mostly) Roger are working on that. At any rate, I think the exact phrase Ed stated was "pretty much everything in faces-config.xml will have an annotation." While most things are pretty straight-forward (components, renderers, managed beans, etc), navigation, which is the second part of your question, is a bit trickier. What would one annotate? Unless I've missed something, there hasn't been much talk about what that will look like. With regard to Seam/WebBeans, at this time we're not planning duplicating the effort there, but we do have a member or two on the Web Beans EG, and are planning are integrating as cleanly as possible with that spec.

Currently, and I hope I don't get in trouble for saying this :), we plan to have a Proposed Final Draft out by 9/18, along with every other EE 6-related spec, it seems. Of course, schedules and plans being what they are, this may change. Time will tell, of course.

I should also note that everything I just said is still under active discussion and development, so it may change by the time the final spec is delivered. It's also important to point out that this *my* perspective on the state of things, so I may have things a bit inaccurately in my head, but I've done my best. :)

Thanks for a great coverage of the conference. It's certainly more detailed and thoughtful than my own. I should also note that Core JSF was invaluable to me lo these many years ago as I got started in JSF. Great book. Can't recommend it highly enough. :)

"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." Actually, you get the boxing/unboxing with the control invocation by providing only one variation. Try it with the prototype! "Non-local return is bound to be confusing. I still hope that this can be salvaged. Perhaps by outlawing return outside control invocations, but Neal Gafter doesn't like that." Actually, in the current prototype a closure written with '=>' may not use a nonlocal return. It is outlawed. I wrote about this months ago: http://gafter.blogspot.com/2007/12/restricted-closures.html . "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." Yup. The same "problem" occurs with all closures proposals, even his. BGGA requires a compiler diagnostic in this case, which is implemented in the prototype.