The two sessions that I attended were:

- RubyTooling: State of the Art
- Using Ajax with POJC (Plain Old JavaServer Faces Components)

I attended the first session simply to get a little more detail on all of the hype surrounding Ruby tooling support in NetBeans 6. What I got was even more than I bargained for. The project leaders actually walked us through not only the features that were available, but how they were implemented. I had never really thought about the problems with providing code completion and refactoring with a dynamically-typed language. It was really cool to see the thought process that went into their solutions. I’d love to hear a similar discussion from the JetBrains guys, as the Ruby support in IntelliJ IDEA is quite good as well.

For me the second session was the best of the conference for me up until that point, and arguably it still is after attending Friday’s sessions. Craig McClanahan, of Struts fame, was the main speaker and was joined by his colleagues Matthew Bohm and Jayashri Visvanathan. What made this session so good for me was that they presented a problem – “How can I add Ajax behaviors to my JavaServer™ Faces technology based application, without throwing away my investment in existing component libraries?” – and then provided three different solutions to that problem – low, medium, and high level.

The low level consisted of simply using the HTML event pass-through attributes that are implemented by most standard JSF components (onClick, onBlur, etc.). One could use an existing JavaScript framework such as Dojo to send an XMLHttpRequest and then map that request to a Servlet or JSF handler using a technology such as Shale Remoting. The response could be sent back as JSON data which could then be transformed into the desired UI update.

The medium level consisted of actually extending existing JSF components and adding the desired Ajax behavior. Due to time constraints they didn’t cover this solution in detail, but they did provide a link to a detailed discussion in the Java BluePrints catalog: https://blueprints.dev.java.net/bpcatalog/ee5/ajax/extendingRenderFunctionality.html

The high level solutions addressed the following needs (copied directly from the slides):

● Partial page submit—gather up a particular set of
input element values, and send them to a bit of server
side business logic
● Partial page refresh—the business logic needs to
refresh the content of one or more subtrees of the
client side DOM
● Synchronization—the benefits of synchronizing the
server side state
● Don’t repeat yourself (DRY)—reuse existing
components and renderers for partial page updates

To address these issues, the speakers highlighted two add-on frameworks:

● Ajax4JSF (http://labs.jboss.com/portal/jbossajax4jsf)
● Dynamic Faces (https://jsf-extensions.dev.java.net/)

I was quite impressed with both of these frameworks. One of my colleagues is currently implementing Ajax behavior in a Facelets-based application using Ajax4JSF and he is quite happy with it. Dynamic Faces looked really awesome, especially its tooling support in NetBeans (actually I’m quite impressed with the overall JSF support in NetBeans – I’ll definitely be adding it to my tool belt). The highlight of the presentation was Matt’s video of him building an entire currency trading application in 28 minutes – except it was “fast-played” to finish in 3 1/2 minutes and set to techno music. Matt wowed us with his dancing abilities while we watched true RAD. The crowd went wild!

It has been a whirlwind of a day. I’ve been to two keynotes (close to 5 hours of information there) and one technical session. Couple that information with what I heard at Java University yesterday, and you find many common themes. One that keeps coming up is the emerging trend of making other languages, particularly dynamic/scripting languages, first-class citizens on the JVM.

According to Wikipedia, “Dynamic programming language is a term used broadly in computer science to describe a class of high level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, or by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.” This definition seems to fit quite nicely with what I’ve heard the last two days. A couple of dynamic languages I’ve heard A LOT about are Groovy and Ruby.

Yes, Ruby and its most popular framework, Ruby on Rails, have survived the initial hype. They are here to stay. Not only that, they seem poised to make a serious impact on the way we will do web application development over the next several years. Sun made a HUGE splash when they decided to hire the core developers of JRuby, the project which in its current pre-1.0 release already runs 98% of Ruby on Rails as a first-class citizen on the JVM. Not only that, you can now create a WAR file from a Ruby on Rails application and deploy it to any Java application server! I’ll write more on this in another entry as I attended a full technical session on it.

If you’re too uncomfortable getting away from Java, why not try Groovy? After all, it is a JSR (241). All of Java syntax is legal in Groovy, plus a lot more. Groovy is a dynamic scripting language like Ruby and also compiles to bytecode, making it a first-class citizen on the JVM. It has its own MVC framework, Grails (formerly Groovy on Rails), which is a direct competitor to Ruby on Rails. I’ve already written on Groovy and Grails in an earlier entry.

I plan to attend some additional sessions focused on these dynamic languages, as it seems they will be really important in the years to come.