Skip to main content

Java One Day 2

Posted by cayhorstmann on May 7, 2008 at 11:30 PM PDT

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)

style="float: right; margin-left: 1em;" />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


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 href="">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

  • 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

Web Beans (JSR-299)

style="float: right; margin-left: 1em;" />Gavin King talked about Web beans.
I wanted to know whether/when we have will have something like href="">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 href="">Patrick Curran (the href="">JCP Chairman), href="">Alex Buckley, href="">Stephen Colebourne, href="">Rod Johnson, and other

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 href="">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. width="106" height="106" style="float: right; margin-left: 1em;" />It is to
Sun's great credit that we get access to their executives, and that they even
listen to us (in href="">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

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 href="">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.


I'm glad there is more talk about transparency in the JCP. I started a discussion about this on JavaLobby some time back and Han's work on the Swing App Framework has been a good example of transparency. John Rose's work on the invokedynamic JSR has also been exemplary (he's also a regular contributor to the JVM Languages Google Group). Let's hope we see more of this in the future, it can only lead to better JSRs, IMO.



>>> Now we'll have to see how he likes the Flex stuff at his new employer Adobe I know Chet Haase now works for Adobe, does Hans too ?

You know what happens, when you ship a bunch of properties files for translation, and the translators sees stuff like: infofield1.font=Arial-PLAIN-12 and submit.Action.accelerator=control S? Yes, they try to translate it, it becomes quite a mess.
Also, NetBeans often has a hard time with it. Try to refactor the name of an action method for instance, and see your app fails silently.
I am no fan of this overuse of resource injection and binding at runtime, but I guess that's what Hans had to work with. Now we'll have to see how he likes the Flex stuff at his new employer Adobe, where they have real properties and binding in the language.