This year, I got a genuine press
pass from a kindly soul at Sun. While my quest for priority seating was
still futile, I made progress on my quest to locate the stash of free
booze, and I got the chance to ask more hard-hitting questions. Here is
your intrepid reporter's take on day 2.
Last night, our cat, Mr. Darcy,
escaped, and it took a couple of hours to locate him. As a result, I
overslept and missed Gavin King's presentation on Web Beans. That's too
bad—I enjoy Gavin's presentations, particularly since he isn't shy
about voicing his opinions. I looked at the slides and was amused by this
bullet point: "True AOP is a boondoggle—an absurdly overcomplex
solution to a narrow range of problems."
Off-topic: Check out the Greenfoot entries.
Linda DeMichiel gave an overview about JPA 2.0. (If you haven't looked at JPA 1.0, you should. It is very developer-friendly and you can learn it without ever bothering with the nasty parts of the old EJB. You can use it in standalone or plain web applications, outside an EJB container.)
JPA (as part of EJB 3.0) was a great start, but it was a 1.0 release. Some open issues and ambiguities, a few bugs, and some missing pieces. In 2.0, expect clarification, reduction of non-portability issues, and some enhancements. It's a new JSR, completely decoupled from EJB
The enhancements seemed pretty straightforward. Embeddables can contain other embeddables; the whole hierarchy gets flattened. Sets of primitives and strings can be declared conveniently. One-to-many bidirectional mapping will be supported. The table-per-class inheritance strategy will be required.
My pet peeve will be addressed,
and we'll get some kind of ordered lists. That is, when I persist
@Entity public class Quiz
{
@OneToMany @Ordered @OrderColumn // strawman syntax
private List<Question> questions;
}
the order of the question is remembered, by storing an index into another column. There is a headache about inserting into the middle in the list; she wasn't sure how that would be addressed.
JPA 1.0 forces single access type (either fields or getters/setters) for every entity hierarchy. I don't think I care since I always use fields. Then again, maybe I do, if I want to use getter/setter for debugging in one case.
Some JPQL limitations will be removed. You'll be able to say
SELECT d.name, SUM(c.hourlyRate * c.hoursWorked * 52) FROM Contractor c JOIN c. dept d GROUP BY d.name
There will be some syntax for dynamic queries where one adds criteria objects rather than building up strings. It sure would be nice to have a domain-specific language rather than cumbersome chained method calls, but Java doesn't support DSLs (yet?)
Configuration hints will be provided in a uniform way, not ad-hoc escape hatch. Obvious candidates: JDBC params, timeouts, logging, DDL handling. Put them into javax.persistence namespace
We'll get better support for detached objects (another pet peeve of mine): fetch plans, predictable behavior when unfetched state is touched.
Depending on timeline, there may be alignment with the general-purpose validation mechanism of JSR 303.
Overall, it seems like an evolutionary improvement of an already very good API.
My Core JSF coauthor, David Geary, has just finished a book on GWT and keeps telling me how cool it is (“Swing for the web”). I knew nothing about it and was skeptical when I first hear that they translate Java code into huge gobs of client-side JavaScript. But I was quite impressed with the presentation.
I am more than a bit scared of writing Ajax code myself. With JSF, I can presumably just drop in someone else's well debugged Ajaxified component. I don't actually hate writing JSF (well, except for the Stack Trace from Hell), but I don't enjoy it much either. GWT seems non-scary, even fun, especially if I can figure out how to use JPA on the backend. I'll give that a try in my copious spare time.
At the show floor, I stopped by at the Eclipse booth and kvetched about how tedious it is to install the plugins for JSF and JPA, and how much easier it is to just use NetBeans. The fellow at the booth turned out to be Mik Kersten, the creator of Mylar. He agreed that Eclipse needed to get their act together with packaging but he still felt that it had an edge because there are so many cool plugins such as, well, Mylar. He gave me a demo, and it was cool. You can deal with bug tracker issues right in Eclipse without ever going to Trac or (blecch) Bugzilla. Bugs are tightly tied to code lines. Also, Mylar remembers the parts of code files that you have recently looked at and hides everything else. You focus on the stuff that you care about, not the mass of other files in the project. Here is a better explanation with screen shots by Kirill Grouchnikov.
I am glad that we have both Eclipse and NetBeans around.
It's a Java One tradition. They take an ugly Swing app and add gratuitous eye candy with as few lines of code as possible. Such as:
The table effects had pretty nasty looking code, though. I called it quits and went to a press-only round table discussion on JCP.
There was a distinguished panel, including Danny Coward, Linda De Michiel, Hani Suleiman, a bunch of folks from big corporations, and the director of the JSR program, Onno Kluyt.
Someone asked the obvious question: What is the difference between the JCP and OpenJDK. Answer: The JCP defines what Java is, the OpenJDK provides an implementation. There can be only one Java standard, but there can be multiple implementations.
I asked hard-hitting questions about the lack of openness in the expert group deliberations, and the risk of expert groups with tunnel vision delivering less than optimal results. It might have been polite not to cite JSR 127 as an example, but I showed no such restraint.
Answer: (1) The expert groups in the smoke-filled back room are a sign of the past. Nowadays, the process is much more open. There are multiple interim deliverables so that unhappy stakeholders can squawk early, and many JSRs have open mailing lists. (Onno told me later that he would like to see that as a requirement, not just an option, at some point in the future.) (2) If a JSR goes off the deep end, the executive committee can stop it.
When the discussion petered out, someone mumbled something about "cocktails in room 114", and off we went. Apparently, the secret to free drinks is to stick it out until the end.
I was so proud of my foresight that I had reserved a seat for the F3 presentation, long before I knew that it would be the star of the show and prepared to smirk at a long line of people without pre-registration. But there were plenty of empty spaces.
Chris Oliver gave an overview of Java FX Script. (Doesn't that just roll off your tongue? After a couple of failed attempts, he just called it JFX.)
He started out asking:
As we all know from the keynote, JFX is the solution: a toolkit to produce flash-like GUIs with a declarative programming language.
The language is interpreted; it will be compiled at some later point. It is statically typed.
You build component hierarchies in which every line, rectangle, etc. is a component. Any Swing component can also be included. You declare properties for each component, such as position, color, transparency, transforms, filters (glow, noise, etc., like in Gimp/Photoshop).
If Java allowed for domain-specific sublanguages, could this be done in Java? Or Groovy? (Chris Oliver doesn't believe in duck typing and isn't shy about saying so.)
There is a bind keyword for binding values/components (?) together. When a one of them changes, the bound entity also changes. An example: We have an animation
rotval = [0...360] dur 1000
That is, rotval goes from 0 to 360 in 1000 milliseconds. Bind a rotation transform property of a rectangle to rotval. As rotval changes, the transform changes, and the rectangle rotates. That's how one avoids the writhing mess of listeners. According to Chris, data binding is not a part of any mainstream language. It can be found in functional reactive programming languages.
In the Q&A, Elliotte Harold asked why not just use SVG. Answer: SVG behavior is specified by JavaScript operations on the DOM, which is less declarative and messier.
At the end, there were more flashy demos. Chris: “Whatever you can do in Flash, you can do in Java. JFX gives you a faster way of expressing it.” (I should have asked “What about multimedia?” I'll have to work on my reporter skills.)