Skip to main content

Java One Day 1

Posted by cayhorstmann on May 6, 2008 at 11:35 PM PDT

Here is my braindump from Information Overload Central, AKA Java One 2008.

Java FX Script

The day started with, you guessed it, another keynote. I just can't stay focused during them, so FWIW, here is what I got out of it.

  • Sensors let you figure out whether people leave a keynote early.
  • RFID tags are a mixed blessing. In passports, maybe not...Chief scientist John Gage: “Hi, I'm an American. Can you detonate the closest device?”
  • Sun's VP for software Rich Green promises huge announcements, great surprises. He also says that Sun is the world's largest open-source software provider on earth.
  • A fellow from Amazon (the shopkeeper, not the river) demonstrates the Kindle which, as it turns out, is a Java ME device. I never knew that. Actually, I think that is good news. Amazon quietly picked what they perceived to be the best technology for the job. That's a much more credible validation than the usual co-marketing arrangements (like those tacky “Intel inside” or “Designed for Windows” stickers.).
  • Here is what was best about the Amazon demo. The fellow demonstrated how to buy a Java book. And which book did he pick from the multitude of choices? Yes, my friends: Core Java, authored by yours truly. He mumbled that it seemed to have good reviews.
  • One thing that always bugs me about keynotes is when partner from company X appears on the stage to share ... absolutely nothing. Can anyone tell me what value the fellow from Sony Ericsson added?
  • The highlight of the keynote was Java FX Script. The pitch was that there is intense competition for consumers' eyeballs, and that rapid prototyping and frequent iterations are essential to develop the killer UI that captures those eyeballs.
  • There was a cool demo where an applet was dragged off the browser and dropped onto the desktop. I really liked that part. The applet—written in Java FX Script—also ran (somewhat degraded) in a low-rent ME phone. There was another cool demo with spinning video players, all running at a good speed.
  • Delivery timeline: July 2008: JFX SDK EA. Fall 2008: JFX Desktop 1.0. Spring 2009: JFX Mobile 1.0
  • The Glassfish 3.0 kernel is 98K.
  • Open JDK ships in Ubuntu. (To my delight, there was a fair amount of applause from the audience.)
  • Sun is working on Project Hydrazine. Find. Merge. Deploy. Share. Monetize. Huh. It has something to do with instrumenting Java FX apps and sending data back to the trustworthy service deployer, not the evil technology vendor.
  • Jonathan Schwartz is much better at explaining stuff. His take on Java FX:
    1. More devices: Linux, Mac, Windows, embedded devices
    2. Performance (better VM)
    3. Insight (instrumentation)
    4. Free
  • The keynote ended with Neil Young, a bard who pitched a multimedia project that chronicles his life work on a set of Blu-Ray disks. The UI was very pretty...Java-powered, of course.

A few months ago, I had asked Bob Brewin at Sun about the situation about audio and video codecs in Java and FX. He hemmed and hawed and mumbled something about how Ogg Vorbis wasn't really going to work out. The good news is that Sun now licensed the same codecs that are used in Flash, and there will be decent multimedia support going forward. It is just extremely annoying that codecs are so patent-encumbered, and it is yet more evidence that patents hinder, and not promote, the progress of science and the useful arts.

At the press cocktail hour, James Gosling was kind enough to give me some inside dope on JFX development. One of my graduate students, Sadiya Hameed, is working on reimplementing Java FX Script as a DSL. Whenever she showed me some code that she found in the wild, I thought “Whoa! That's a lot ofmath.” (Which, BTW, one of the keynote speakers said today as well.) As it turns out, a lot of the math is apparently auto-generated when a set ofAdobe Illustrator files is transcoded into Java FX Script. The work flow is that the creative folks work in the tools that they like (and not so much in Java FX Script), and that the programmers work in the tools that they like (maybe Java FX Script for the front end, and definitely Java on the backend). Gosling also said that some of the tools were still pretty rough, which is why the keynote didn't show them off. That all made perfect sense. They should let him give the keynote next year.

EJB 3.1

I am a definite fan of JPA and EJB3, so I was keen on learning what is new in EJB 3.1. Fortunately, much of it centered on my pet topic, ease of development.

  • No more boilerplate local interfaces. Session beans can be POJOs. Hooray.
  • Packaging complexity bites the dust. No more EJB JAR inside the EAR. Hooray.
  • Work in progress:
    • Standardized JNDI lookup
    • Component testing in lightweight container
    • Using EJBs in single SE client (lookup, injection)

It surprises me how many people still don't realize that EJB3 was a game-changer. Last year, it was still ok to complain about EJB bloat. This year, not so much.

Defective Java

Bill Pugh gave an amusing talk about “WTF code”. He is the inventor of the nifty Findbugstool and regularly trolls for dysfunctional code (in unsavory places such as this one) to add more bug-finding rules. Here are some of the beauties that he presented:

  • while ((c = (char) != -1) { ... }

    A char is a value between 0 and 65535, never -1...

  • private final String lock = "LOCK";synchronized (lock) { ... }

    Literal strings are interned, so hopefully two programmers don't have that bright idea...

  • synchronized(getClass()) { myStaticCounter++; }

    Let's hope nobody calls this from a subclass...

  • DateFormat is not threadsafe...
  • java.sql.Timestamp is not symmetric...
    The audience's collective eyes glazed over at this point. An informal poll revealed that a large fraction was blissfully unaware of the instanceof vs. getClass() controversy in the equals method. This seems to be a lost cause. Maybe anyone who overrides equals in a non-final class needs to supply an annotation @IKnowWhatIAmDoing.

Java Language Evolution

An interesting presentation about what to expect in Java 7 and beyond.


  1. Respect the past. No new global keywords (like enum, assert). “Restricted” keywords are ok (module, and hopefully, property :-))
  2. Respect the future. Leave room for syntax to breathe. Counter-example: Maybe we'd like to have named parameters for ordinary methods in the future. When annotations with named parameters were introduced (@Foo(name = "fred")), the choice of = was a mistake, because you can't do foo(name = "fred") for ordinary methods. Had the Java 5 designers respected the future, they would have chosen something like @Foo(name : "fred"). Or not...wouldn't that conflict with BGGA control invocation?
  3. Respect the model. Java is a general purpose OO language.


  1. High-level. (Express the idea, not the bits)
  2. Covet clarity
  3. Static typing
  4. Loose coupling between language and API

Likely to be in Java SE 7:

  • // Multi-catch
    try { .... } catch(X1, X2 e) { ... }
  • Modules
  • Annotations in more places

Definitely won't be in Java ever:

  • Operator overloading

style="float: right; size: 50%; margin-left: 1em;" />I want the multi-catch.
Modules and better annotations are noble but dull. Did I ever mention that I
want native properties? That I am sick of the href="">boilerplate?
I asked James Gosling. He said that there is a long stack of proposals on
what to do with properties. And they all run against a
brick wall when they try to deal with bound properties. (I of my students, Nikolay Botev,
compiled a long list of them, and another, Alexandre Alves, implemented a
javac extension to implement one.) I agree...bound
properties are a lost cause. Let's just admit that and move on, with simple
properties and a “restricted” property keyword!

Too bad I didn't have a chance to ask about that in the BOF. I had been a
reviewer for the tools and languages track, and Sharat Chander, the track
chair, took out all of the reviewers for a great dinner. Potentially little known
facts: (1) Competition for slots at Java One is intense. We had over 300
proposals for maybe 20 slots. (2) Most of the reviewers—at least in our
track—are not from Sun.


Definitely won't be in Java ever: Operator overloading

So, we'll forever be able to add Strings, yet always have to use the .add function to add BigDecimals, Vectors, Matrices, and other mathematical types. Smart. Lack of operator overloading just adds to the stigma that Java is only for IT applications.

Thanks for the detailed run-down for those of us not able to make it. The multi-catch seems like some nice syntax. I am probably asking for trouble but I was wondering what you think of my idea for reusable exception blocks.



dead on & thanks for saying it: partner from company X appears on the stage to share ... absolutely nothing

@quintesse: Ah, yes, the ever present "but someone will abuse it" argument. If I rewrote the command to be socket.feonjafajfaf(message), I can only assume that you would find the function to be clear, concise, and meaningful since I didn't use a mathematical operator.

The people that most want operator overloading are those that do math and would use it appropriately (scientists, engineers, mathematicians). Unfortunately, the Java space seems to be dominated by IT and enterprise developers who don't have a need for OO and only see it only as something to be abused. The real solution to your problem (OO abuse) is to walk down the hall, knock on the door, and say "don't do that" to the guy who did it.

Modules dull? I beg to differ! I think multi-catch exceptions are dull! (Very usefull... but sull)

Modules and the related packaging and repository support will profoundly change the way we deploy applications though. I can hardly wait :)

@jeeky: Just the other day I saw an example of operator overloading in Scala:

socket ! message

which would send the message over the socket. My only reaction is "what were they thinking??". Socket.send(message) works perfectly well thank you, I don't mind typing a couple of letters more. Now if there was a way to assure that operator overloading could only be applied to numerical/mathematical types, ok, but I imagine that might be diificult to do.