Java One 2009 Day 4

The Toy Show

One of my favorite parts of Java One is the Friday morning “toy show” where James Gosling presents a random mixture of cool and inspirational projects. Of course, all these involve Java in some way.

The BlueJ team received a well-deserved special recognition for building tools that help millions of high school and college students get started with Java.

A fellow from RuneScape dev demoed their tools, and I learned how one animates a water troll, something that will surely come in handy one day.

There was a wacky demo involving a Wii infrared sensor and infrared LEDs that guide a projector. One of them lets kids draw on a virtual wall. I want it for the Horstmann twins.

Tor Norbye, the demo stud, showed a very impressive JavaFX authoring tool whose release is planned in December. I admit that I was dubious about Java FX when it was first released, but it is looking much better now. At least when Tor demoes it...

There was a demo by the high school kids who won the FIRST robotics contest. Sun and the FIRST folks just oorted the programming environment from C/C++ to Java. They hope it will lead to more interesting robots in the future—right now, the students struggle enormously with core dumps. They need volunteers—check out their web site. What's in it for you? “There is nothing more fun than see your program drive on the floor.”

The Grameen foundation showed off an open source system for helping with microfinance in third world countries. They also need volunteers.

SIM cards have now become so powerful that they can easily run Java and a web server. The latest ones can interact with sensors and WiFi radios. A fellow showed how you can mock that up with Sun Spots for easier debugging.

Someone demoed a satellite ground station management app built on Netbeans RCP (i.e., the same platform on which the Netbeans IDE was built), using over 1000 modules. As it happened, Goslings first programming job was in a satellite ground station (he was 14), using a PDP 8. It had less compute power than a modern smart card.

Two Hungarian university students showed off the project that won them first price in the Ricoh printer contest. Those printer/copiers are Java-powered, and the students used them to grade multiple choice exams.

A musician showed off a Java-powered juke box that allows independent artists to upload their creations to a web site and have it played in bars. As James put it: “Here's Manuel. He is a musician. He has a problem.” And with the help of a touch screen, a cash reader, and Java FX, he put together a solution.

“Project Bixby” controls an Audi TT on a dirt rallye course going really fast (160 km/h) without a driver. And finally, the “LincVolt” project controls a 1959 Lincoln Continental with an electric motor, this time with a human driver—another musician named Neil Young. There is a Swing-based control panel. Boy, is it ugly—maybe Java FX can help. What's next? The “Thinkin' Lincoln” that no longer requires Mr. Young?

Technical Sessions

I attended the “JPA Magical Mystery Tour” session. JPA has been a real game-changer, maybe more than people realize. I can now routinely run student projects that involve a database, with a lecture on JPA and a couple of code samples. These are greenfield projects, so there is no need for any SQL. Of course, as the speaker pointed out, in a real project, you don't need to write the SQL, but you still need to understand what goes on. For example, JPA 2.0 has a nifty @OrderColumn for persisting list orderings, but you really need to think about the implementation to understand the costs. The talk started out with the basic mappings and it got a bit mysterious at the end, with attribute overrides and compound primary keys, but it never quite rose to being magical. I had hoped for more details about the magic of the entity manager. Moral: Don't overpromise in your

Bill Pugh gave a repeat of his “Defective Java” talk—the antidote to “Effective Java”. If you haven't used his FindBugs tool, check it out now! He had a sabbatical at Google where he explored how FindBugs does on production code. Interestingly, it found a lot of bugs—over 3/4 of the flagged issues were deemed by Google engineers to be mistakes that should be fixed—but it didn't find many mistakes that really matter. Those had been found earlier, and perhaps painfully, through testing and failures in production. The moral is to use FindBugs early. Bill is now working on a cloud service for community review, where programmers can post previously found bugs. When you evaluate a FindBugs issue, you can then evaluate whether it is likely to be serious.

Our cat, Mr. Darcy, would like to thank Bill for the bug that he tossed my way when I raised my hands as soon as I saw the slide involving Double and ==.

Ludovic Champenois (AKA Ludo) gave a presentation about EE6 tooling in NetBeans and Eclipse—sadly not well-attended at a time slot that is usually reserved for such crowd pleasers as “Enhancing the Role of a Large U.S. Federal Agency as an Intermediary in the Federal Supply Chain via a Service Registry and a JBI-Based ESB”. Ludo is responsible for the Glassfish plugin for Eclipse, which I can heartily recommend. If you just get started with it, download the Eclipse/Glassfish bundle. You get one-stop shopping, just like with NetBeans, with JavaDB configured, all XML schemas, javadocs, etc.

Finally, after having been thoroughly worried about JSR 299 vs. JSR 330, I decided I'd better learn more about Guice, and I attended the talk by Jesse Wilson. Ok, it's a nice enough DI framework. You configure injection with a “fluent” API, not XML. That's nice. But it isn't as nice as WebBeans, erm, Contexts and Dependency Injection. Instead of writing a lot of XML boilerplate for configuring a test of a large system, Guice makes you write a lot of Java boilerplate.

Here is the one thing I don't get about JSR 330. It has this annotation @Inject that tells you that you want to inject something, but it doesn't tell you why. Injection annotations such as @Resource, @EJB, @PersistenceContext, @ManagedProperty, are common in Java EE. I can see the benefit of having a meta-annotation that says “this annotation injects”, but I don't see why you would want a single injection annotation. I asked Jesse about that, and he seemed to say that injection was this big, scary, strange thing that should definitely stare in your face in your source code. Well, in my Java EE experience, injection is your friend, not something that you fret about. So it seems that in its current form JSR 330 isn't very compatible with, say, JPA in a Java SE application, surely a reasonable use case. My suggestion would be for JSR 330 to lighten up, realize that there isn't going to be a single source of injection, and focus on meta-annotations and commonalities among injection providers. Caveat: I am not an expert on this stuff, just someone who looks at it from the outside with some experience in both EE and SE.


Java One is now over, and here are my random conclusions and opinions.