JavaOne 2008 Wrap-Up

This year, I attended the JavaOne conference in San Francisco to see what kinds of new things were happening in the world of dynamic languages. I took a look at the scheduled technical sessions several months ago and saw that there were going to be several covering JRuby, Ruby and Rails, and Groovy and Grails. I didn’t want to miss out on this one. I’ve been watching what has been developing with all of these tools for some time with a lot of interest. This year’s conference was no disappointment. Sun pulled it off once again. I was hoping to determine a clear choice between JRuby and Grails as the direction for my next project. I had it narrowed down to one of these two. I am a Java programmer looking for a new set of tools to play with. I went in with a preconceived notion that JRuby would get the nod and come out a clear winner. I’ve done some very basic work outside of my regular day job with Ruby and Rails and have also attended both the Ruby and Rails Pragmatic Studios. I really like the elegance of Ruby and the ease of developing simple apps with Rails. Taking it one step farther and being able to run Ruby on the JVM makes it even more promising. With RoR, it’s nice to focus on the problem you are trying to solve and not the configuration of your tools and satisfying a compiler. I’m really still very much a beginner. I have just enough experience / exposure to be dangerous. So, here is my take-away from this year’s conference and what I liked about each of the dynamic languages.

The reoccurring theme in the sessions I attended seemed to be that Java the language has ran its course but, Java the platform and ecosystem is very much alive and well and dynamic languages are the hot item. I was particularly interested in the dynamic languages and how they could tap into or interface with Java but, take advantage of the convention over configuration idea. Here is a simple summary of some of the things I like about each of the options. One of the coolest features I like about RoR is the mixins. Mixins eliminate the need for multiple inheritance. The Groovy development team is supposedly working on an implementation of this as well. What are the downsides right now to JRoR? It’s a little extra work to get the environment set-up but, it’s a one-time cost. There is a packaging utility to create WAR files but, I came away unsure about the maturity of the tool. Some issues were brought up about how there are a couple of kinks that need to be worked out with this in Rails 2. If you follow convention, things are OK. If not, it gets a little rocky. Rails expects a certain db scheme. If you deviate away from it, things get a little hairy. Packaging takes some work to get things war’d up because of this app structure. It’s not war friendly but, it can certainly be done. People are doing it. Again, it’s one of those one-time costs. Another concern of mine continues to be around ActiveRecord and how you deal with composition relationships (parent/child/grandchildren). Is that an obstacle? Features like belongs_to take care of the foreign key relationship in the relational model only. I’ve also heard that the learning curve for Ruby can be steep if you are coming from a language like Java. However, the framework is unquestionably easier than the Java offerings. There is a lot of mindshare and community behind RoR and JRoR for no longer than it has been out there. There is no doubt where Sun is. They have thrown their support behind JRoR and have hired the core developers. The Netbeans project also has a lot of really nice features built into it or available for RR development. Some of the demos in the technical sessions were running on the Glassfish application server. Sun really seems to have put their energy behind that as well.. Glassfish has its advantages. You can develop in the same environment that you deploy. You can handle multiple requests by maintaining JRuby runtimes and db connections in pools. Rails is single threaded which results in creating a JRuby runtime instance for each of the concurrent requests. This could end up consuming a lot of permanent heap space. JRoR does look promising. Its integration with Java is a great way to get Ruby into the enterprise.

Switching gears to Groovy on Grails… Coming in, I was looking for clues for why the Java community wasn’t jumping all over this. I have looked at it a little and was pretty impressed. I’m still kind of surprised after attending JavaOne. The GG sessions were heavily attended but weren’t as packed as the JROR sessions. I met more people who were already on Rails. That could be attributed to its head start. Don’t know. GG does most all the things RR does. Groovy code doesn’t look that far off from Ruby. GG also provides some of the ‘coding by convention’ productivity of Rails. I’ve heard estimates that Groovy has at least 80% of the functionality of Ruby. Groovy should be easier to learn for people like me coming from Java domain. It has a familiar syntax. Supposedly, there is a bit of a learning curve with the framework. We’ll see. I intend on digging deeper into it. Right now, I’ve set everything up (which was rather painless) and created a “hello World” app. I’ll report more on my experiences there as time goes on. Migrations is the most obvious thing missing . I didn’t pick up on whether it is in the works. It’s a slick feature in Rails. Metaprogramming is weak in GGG compared to Ruby as well. A lot of this stuff is probably still getting worked out. Bi-Directional Java/Groovy integration is more straightforward as would be expected. GG is Java. I heard that said many times during the week. The integration with legacy systems built with Java is easier. I would think that alone would create some momentum around GG with the enterprise set. It just looks very promising for people who come from Java and don’t want to throw away all their Java knowledge. This looks like a good way to augment what you know. It’s an all Java idiom. It all looks good as long as it doesn’t evolve into what Java is today. One of the presenters in the JRoR sessions brought up a good point. If you are going to use Groovy like Java, there is no point. Another promising thing was that I did hear the Groovy In Action book was a top seller at the conference. The author (Scott Davis) did one of the Groovy technical sessions. In my estimation, he was the best presenter all week from the things I attended. In his session, he gave a presentation that included coverage of the Meta Object Protocol. He showed how you can bolt on new functionality at runtime to classes that are static. Really neat stuff. The ExpandoMetaClass. Overall, I guess I didn’t learn enough to really be persuaded to jump right in and adopt GG over Rails just yet. The jury is still out. In the meantime, I think I’ll build a prototype with each to get into it more. From there I’ll decide which way I’ll throw most of my attention. One thing is for sure. Either one of these dynamic languages would be better than battling Java and all it’s complexity, needless details, and decade-old ugly syntax. I’m personally tired of all the low-level details we have to deal with. Who the hell wants to continue programming to satisfy a compiler?

So what did I conclude? At the moment, I think either choice appears to be enterprise ready. It’s a matter of personal choice and what you feel comfortable with. The momentum right now appears to be behind JROR/RR. However, I’m personally still intrigued with Groovy and Grails. GG doesn’t appear to be a migration away from Java. It looks like you still get to keep your investment and also use your existing base. I’m leaning toward picking an existing Java app of mine and refactoring with Groovy and Grails. However, the rest of my team with the exception of one, seems to be heading toward Rails. We’ll see. Convince me why I should do the same!