Java One Day 2
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
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
annotation, and then set accelerators such as
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="https://beansbinding.dev.java.net/">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
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
Quizclass 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
- 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
the web tier, I will want to prefetch the
and for each multiple-choice question, I want to prefetch the
Choiceentities.) 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="http://www.jboss.com/products/seam">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.
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="http://blogs.sun.com/pcurran/">Patrick Curran (the href="http://jcp.org/en/home/index">JCP Chairman), href="http://blogs.sun.com/abuckley/">Alex Buckley, href="http://www.jroller.com/scolebourne/">Stephen Colebourne, href="http://blog.springframework.com/rod/">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="http://jcp.org/en/jsr/detail?id=127">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="http://www.sun.com/aboutsun/media/ceo/bio.jsp?name=Robert%20Brewin">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="http://javafx.com/htdocs/signup.html">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.