I attended two sessions this afternoon.

The first was “State of the Open Web”, by Mark Pilgrim and Patrick Chanelon from Google. Mark and Patrick discussed an impressive array of new features in HTML5 (canvas, video, and audio tags, offline apps, and client-side databases), the latest and upcoming JavaScript versions (real class semantics, with interfaces, packages, getters, setters, closures, built-in JSON parsing, JQuery-like DOM selectors, and Worker Threads, to name a few), CSS (generated content, transforms, animation, etc.), and vector graphics.

I’m sure that it was not what they intended, but my take-away from this session was that while all of this shiny new stuff looks great on the surface, browser support for it will continue to be spotty for the foreseeable future, and comprehensive client environments like Flash and JavaFX are looking pretty good in comparison. Oh wait…maybe that is what they intended :-)

The second session that I attended was Rod Johnson’s presentation on Spring 3.0 The room was large, and it was packed with eager Spring developers.

There was a lot of content presented, but the overview is that with version 3.0, Spring has been completely reworked with respect to annotations, and the recommended best-practice is to use as little xml-based configuration as you can get away with. For many applications, this may be almost zero.

Spring MVC now has first-class support for RESTful interfaces, but does not conform to JSR311 - if you want that, you can use another project, like Jersey, with Spring.

Spring now has a Flex integration project. Very interesting. I actually started working with it last week. Should be interesting to see how it pans out.

Finally, Rod talked about Roo, SpringSource’s new round-tripping code generator. Roo approximately fills the space of the scaffolding generators in environments like Rails, Grails, Django, and friends. What is really interesting about Roo, though, is that unlike those other environments, Roo round-trips - you can edit the generated code, and then still use Roo to modify it.  I’ve heard this claim several times before from code generators, and it’s always been a disaster. I was wondering how Roo approached the problem.

I went down to the SpringSource booth, and asked for a demo. My question was answered. Roo can round-trip because in addition to generating Java stubs, it generates all of the real scaffolding bits as AspectJ artifacts. When you edit the generated Java code, the AspectJ artifacts remain untouched, so Roo does not get confused - it just re-inspects the Java code, and updates the AspectJ code as necessary. I’m told that as a final step, you can, if you wish, have Roo push all of the scaffolding into your Java code, and remove the AspectJ artifacts. Of course, at that point, you wouldn’t be able to round-trip any more.

Roo is integrated with SpringSource’s Spring Tool Suite (which is now free), and the integration is very slick. However, since I’m an AspectJ user, I asked for a demo of the command-line tool. It’s very reminiscent of Rails, Grails, and friends, but has context-sensitive tab-completion and more context-sensitive help than I remember seeing in the other environments.

The other really nice thing about Roo is that it generates a Maven POM. Nice touch!