Here is my report from day 2 of Java One. I continue to feel diffident about RIA and Java FX Script, the theme of this year's Java One, so I decided to make my own themes: Ease of development, and transparency.

Swing App Framework (JSR-296)

Hans Muller gave a presentation on the Swing app framework, a great example for ease of development. Some people think Swing is dead, but there are more people crunching out Swing apps than VB apps. I imagine mostly corporate stuff. The presentation was pretty well attended.

To customize and internationalize components, set their name property (either programmatically or in the GUI builder), and then populate resource files with instructions such as

infofield1.font=Arial-PLAIN-12
infofield1.icon=dynamite-stick.png

For actions, define a method, tag it with the @Action annotation, and then set accelerators such as

submit.Action.accelerator=control S

This is something I have been waiting for for a looong time—it surely has been reinvented a million times (at least twice by me). Now it will finally be a part of standard Java. The framework has many nice touches: support for background tasks, pesky Mac OS X issues, and saving of session state. If you write Swing apps, check it out! (Also check out beans binding.)

JPA 2.0 (JSR-317)

JPA is one of my favorite “ease of development” technologies. I design my object model in Java, toss in a few @OneToMany annotiations, and presto, I get a database schema, entity caching, and an OO query language. I am not the only one who feels that way—the session filled completely. Of course, there are a few issues in JPA 1.0 that even a casual user such as myself runs into, mostly because the API was designed by database wizards but it increasingly used by people who think in Java, not SQL. I was glad to see that all my pet peeves are being addressed in JPA 2.0:

• Ordered lists (e.g. a Quiz class with a field ArrayList<Question> questions). The order of questions matters to me, and I want an index column to be generated automatically. JPA 2.0 will have @OrderColumn
• There will be support for sets of basic and embedded types, and better support for maps.
• There will hopefully be better support for prefetching lazy relationships. For example, when I detach a Quiz object into the web tier, I will want to prefetch the Question entities, and for each multiple-choice question, I want to prefetch the Choice entities.) The details are still being worked out.

Web Beans (JSR-299)

Gavin King talked about Web beans. I wanted to know whether/when we have will have something like Seam as part of EE 6. For me, the key feature of Seam is that I can hook a EJB session bean immediately into a JSF page. (It is painful to access JPA entities in a JSF managed bean, so right now, I shlep a bunch of stuff from JSF beans to EJB beans. Seam avoids that tedium.)

Gavin is an opinionated and charismatic speaker, but he was opionated and charismatic about a general-purpose plumbing mechanism that, once it becomes part of Java EE 6, will make Seam-like components possible. It was quite interesting if you are into meta-annotations, and the design looked very clean. But I still don't know whether I will get Seam-like ease of development when EE6 ships.

JCP Roundtable

Through the power of my press pass, I got into a “JCP Roundtable Discussion on Open Source and Open Standards”. The table was actually not round, just your usual long table with speakers Patrick Curran (the JCP Chairman), Alex Buckley, Stephen Colebourne, Rod Johnson, and other luminaries.

Some things I learned:

• It isn't just me who can't figure out what goes on behind the closed doors of some JSRs. One of the Java EE expert group members has trouble getting onto the internal email list of the servlet JSR.
• Everyone agreed that transparency should be the default for all JSRs, but it simply isn't so today. JSR-166, which Doug Lea ran completely in the open, just to show that it can be done, is still the exception.
• Alex Buckley said that one important part of transparency is for JSRs to not just publish a spec but to give the rationale for their decisions.

All of this may be rather arcane for most users of Java, but as a book author, I feel the pain caused by a lack of transparency. And, ultimately, so do you. There are some JSRs that are best left unmentioned (such as JSR-127) that would surely have produced better specs if they had received more broad-based input.

Java Champions BOF

The Java Champions are a motley assortment of (Java luminaries|whiners and complainers), including yours truly. It is to Sun's great credit that we get access to their executives, and that they even listen to us (in Bob Brewin's case, not for very long :-)). Today, we had a BOF where we got to do what we do best, and one of the common complaints was lack of transparency.

Consider the case of Java FX. I am rooting for Sun and FX. You can't win if you don't fight, and I give Sun a lot of credit for fighting.

I don't see what good it does to develop behind closed doors, and only show a preview to a select few who sign up and get chosen. That may work if you really know what you are doing (e.g. the iPhone but not the Newton). But there is a reason that open source projects succeed with a transparent development process where everything is out for anyone to see. Let people whine and complain early and often, and you get great feedback what you need to fix, before it is too late.