This is my third day of reporting from the floor of Java One. I ran into a number of very interesting folks, got the chance to ask more hard-hitting questions, and had a mixed bag of sessions.
I started out with a presentation on the architecture of GlassFish v2. The speaker said parenthetically how more service providers were offering GlassFish hosting. That's welcome news indeed. Right now, everyone will gladly host your PHP app, but try finding a host fo JSF+EJB3 at reasonable prices.
Unlike v1, which focused on delivering the EJB3 technology, v1 is an enterprise scale server with clustering/failover, and support for WSIT and JBI. I can already tell that I am totally out of my depth. (It seems kind of sad that one needs a technology for web services interoperability—wasn't that the point from the outset?) I am afraid I wasn't the only one. The presenter went on to say how they needed an open source, lighter weight alternative to HADB, and he polled the audience on their knowledge about HADB itself. Not many hands went up.
The speaker did a great job explaining what goes on under the hood, and I learned a bit of how replication and failover worked. I gained tremendous respect for the hard problems these folks are solving. But then there were rounds of applause from the neighboring room, and I left for greener pastures.
The applause came from the NASA World Wind presentation. Unfortunately, I had missed all the cool demos and got treated to more architecture slides. The hardest problem for them was image selection—the user zooms in, and each tile is several megabytes in size. Which images do you show? Another problem that I am glad not to solve. Interestingly, the speaker said "I gave up on Java 5 years ago, but it has come a long way. I am back."
Audience question: "Can I cache the data locally? Or is that terabytes of data?" Answer: "Petabytes (laughter from the audience). But you could pick the terabytes you need (more laughter)".
I cornered Chris Oliver at the Sun booth and he was kind enough to answer some impolite questions about Java FX Script. (Doesn't that name just roll off your tongue?) Why not just build a domain-specific language on top of, say, Groovy? Groovy is slow and not of the highest quality. Isn't it a burden to have to learn another language? Programmers are smart people, and it won't be a big deal for them. Is he happy about the support he is getting from the NetBeans team? That's not his concern; someone at Sun will make it happen. What about multimedia? Java multimedia support has problems; someone at Sun will need to fix that. He is happy that he is getting a first-rate person to write the compiler; that means more to him than being featured at the keynote.
On a completely different topic (that is dear to my heart but quite possibly not to many of my readers), I had a good conversation with Stanley Doherty of Sun about DITA. When I write books, I use FrameMaker. It hasn't been updated for ages; it doesn't even have basic comforts such as multiple undo. But it has one endearing feature. As an author, I can use a handful of tags (code, note, heading1, figure etc.), someone else can prettify it to the point of a printable PDF, and then I can work off the prettified version for the next edition. But everyone wants to move to XML. I do a lot of casual writing with XHTML+CSS, using XMLMind and Prince. I always told myself to learn DocBook, but Stanley thinks I should learn DITA instead—it's simpler and has momentum. I'll definitely look into it.
Brian Goetz did the book signing for his excellent concurrency book that you all should buy. He had been kind enough to read the concurrency chapters in a couple of my books and gently disabused me of my naivete. We talked about how hard concurrency is, and that there would be a lot of blood on the floor with multicore and the end of Moore's law. He said that the best solution would be something analogous to garbage collection for concurrency. Then the VM and not the programmer would figure out how to get concurrency right. This may happen at some point in the not too distant future. He suggested that I read this article.
Off topic: Maybe generics is too hard? The JavaOne TODAY magazine (btw, whatever happened to carbon neutral???) had this depressing paragraph: “If you are new to generics, you might assume that generic collections are polymorphic. In that case, it would be correct to assign an object of type List<Item> to an object reference of type List<Object>. However, such assignments produce compile-time errors.” Well, that's how it must be. There is no ListStoreException, and there can't be because of erasure. Would it have been better to forego erasure, have collections remember the element types, allow conversions to supertypes, and give runtime exceptions, just like arrays do?
In the afternoon, I went to Rod Cope's Advanced Groovy session. I didn't think it was all that advanced, but it was kind of cool to see him use a Swing program to drive an Excel spreadsheet, all wired together by Groovy.
The GlassFish v3 talk was a bit of a disappointment too. GlassFish v3 has a module-based architecture, loosely based on JSR 277. That's why it started up so quickly in the keynote demo. That's kind of cool, and I learned a bit about modules and classloaders and Maven 2, but it didn't really help me be more productive with GlassFish.
Afterwards, I cornered Jerome Dochez and asked him what he was doing about another one of my pet peeves, the Stack Trace from Hell. When something fails, I want the IDE to point me to the offending file name and line number in my code, not show me a humoungous stack trace. He agreed that the module system per se did nothing to address this, and he suggested we meet after Java One. I'll take him up on it. This is actually a hard problem to solve, as one of my graduate students knows only too well. Chunming Dong is working on getting accurate error information all the way from JSF/JSP through GlassFish to NetBeans. Each time I meet her, I repeat the mantra: File name/line number, File name/line number.
I feel like we are in the Cambrian Explosion period of web frameworks. JSF, GWT, Phobos, Rails, Rife, Tapestry, even PHP and ASP.NET have some great benefits. But this can't go on. At some point, evolution needs to winnow down the field.