Thoughts on Thursday’s JavaOne events…

Well, thanks to missing the announced schedule change, I missed the VB in Java session. I will have to go back and check that one out online. The JAX-B session was good. It is really nice to see JAX-B finally not suck. Going back to my previous post on XML in Java, JAX-B 2 is a great half step there.

Another really interesting presentation was from Ronald Simmons, Sean Merritt and James Gammill on the ComputeCycles project. This is an attempt to build an on-demand grid computing solution for Java. The usual suspects make an appearance: JINI, JavaSpaces. It also uses Glassfish as the manager server and for codebase deployment. It is still a little feature thin, notably, IMHO, lacking prioritization, but it is a off to a great running start and would seem to have a smart and committed team.

The “Top Ten Ways to Botch an Enterprise Java Technology-Based Application” session was really good. A lot of it is stuff I suspect many of us have learned the hard way, but it was a nice coherent view and there are definitely a few insights to be gleaned.

The big After Dark party with the Mythbusters guys, fatal1ty and AC/DShe was there. Lines were long, room was crowed, but all in all it wasn’t bad for a corporate party.

Finally, It was the great Web Framework roundup night in the BOF sessions. The evening BOF sessions included Grails (Rail-ish in Groovy), RIFE and Trails. The differences were striking.

Grails is an impressive framework. It is generally based around automatic creation of scaffolding from Groovy objects that become Entity beans. There was a minor debate about the nature of its operation vs RoR and Hibernate. Funny, because as Graeme was giving the talk, Fleury and Gavin were in the back of the room.

The discussion centered around whether your domain objects, in this case, in Groovy, or your RDBMS should be the “starting point”. One questioner (sorry if you read this, I didn’t catch your name) made a point of noting that RoR using the DB as the base and mapping proceeds from the deltas. Grails uses Hibernates DDL tools to generate or modify a database based on the Groovy/Java objects.

Now, I have to sound off on this:

The database is authoritative.

Look people, we have a whole professional class devoted to knowing EXACTLY how the database optimizes things. Hibernate’s “Update” feature, while fine for green dev projects is a HORRIBLY bad idea on a production system. Especially one where you share access with legacy code (BTW, Chris Nelson from Trails at least acknowledged this up front, though his system is also based on Hibernate). Gavin shouted out in the middle of this that Hibernate Revenge(?) will reverse the DB, which is a valid point, however, the discussion at hand was in the scope of Grails.

RIFE is something that has always impressed me. It is a really good basic framework for rolling. The presentation also emphasised its flexibility — you can pick and choose which parts you want to use. It has its own templating system, and a “controller” level that, I think, encourages “considered harmful” programming. however. There is something impressive about the serious full-stack nature of the effort. While few of the decisions made represent what I would have done in similar circumstances, it reminds me of the few web frameworks I have put together in the course of many years in the professional services world. It is a bag of tricks derived from repetitive need, and I can’t hold anything against that.

Trails is, frankly, the most beatiful of all these. There is no “scaffolding” just a clever inspection layer that can look for your entity beans and instantly give you a CRUD app for them. For the fast and dirty, it is really ingenious. Moreover, I can’t help but think that using the new NB RE tool (which spits out JSF scaffolding that bites next to trails) to spit out your entity beans would make this about damned immediate to go to an app. It has a fairly good security model and — and let me go to a religous argument here — doesn’t generate code. I am still part of a school that thinks that if you are generating code, you are doing something wrong. Yes, I know the dynamic languages let you do MORE at runtime, but that is a bit arbitrary.

As an aside: I went to the “Dynamic Languages on the JVM” session today, and I still don’t see why providing a compiler-generated interface for all concrete objects so that they can get a Dynamic Proxy associated with them doesn’t solve at least half this problem… but whatever.

RIFE, of course, has it’s own templating, but to its credit, it is replaceable. Trails is closely tied to Tapestry and Grails brings us GSP, a retread solution to a problem we don’t want. Of these options, RIFE is definitely the winner, but it is really hard for me do dis the code elegance of Trails.

The worst part is, all of these and Seam next to the old standbys of WebWork and Struts, I still don’t see anything that makes me think it is “the” answer to the J(2)EE problem. Scalability matters, and they just don’t seem to have it quite right yet. While they all take different tacts, and each has a single spotlight feature or two, none seems to have it altogether, and I guess the real question is, how much can you take “architecture” out of the mix and still get something that is truely scalable. Moreover, how do you get a nice app with minimal… trash.