The Grails journey begins

After working with ColdFusion and becoming frustrated with some of it's shortcomings, I decided to use a "grown up" language; Java.  It's been quite a few years since I made the leap to Java, and it has been a very interesting journey.  I have had the "pleasure" to work with many different frameworks, tools, and technologies.  With each I began with the same goal: to find an easier way to do X, from looking for an easier way to parse XML (JAXB, XmlBeans, etc.) to something as trivial as sending an email (JavaMail, Spring's emailTemplate, velocity for templating, etc.), I would always think back to just how "easy" it was to do many of these mundane tasks in ColdFusion.

Every time I would run into one of these challenges I would begin an internal debate about whether I should return to CF.  Each time the same objections came up: IDE support was horrible compared to java, ORM support was immature for EE development, and a big one being the cost of obtaining a CF license for my projects.  Yes, there are open source CF engines, but at the time they were immature and I did not feel they were production ready.  Each time I would choose Java, and selected a framework to build against (most recently the full Spring 3.x stack).  With the release of CF9,  ColdFusion now has built in ORM support (it uses hibernate), and decent IDE support (CFBuilder), but the costs remain.  So I still end up choosing java.

The part that is the most challenging to me with Java is the requirement to have knowledge in so many varied technologies to get a "RAD" environment up and running successfully.  As an example i'll use my last project which was based on Spring.  I wanted to build a web application, backed by a database, and deploy it on tomcat.  Seems simple right?  Getting a working configuration took many hours of scouring the internet, reading (very well written) spring docs, books, and fiddling.  Which TransactionManager to use?  Which DataSource implementation?  Should I configure the OpenSessionInView filter?  Many of these questions I have spent years learning the answers to, but the pain to a new developer is enormous, and many times fatal.  While each of these questions are needed to allow for maximum flexibility, they force a required level of knowledge on the end user.  When I look back to my CF days, to connect to the database it was a simple matter to define a datasource, and then use - a much different experience to the user.

Ruby on Rails (RoR) has shown how a framework paired with a dynamic language can offer extreme productivity gains while reducing the knowledge that a developer must possess to be effective.  I feel that if I move to RoR that I would lose many years experience in Java to gain rapid productivity, instead of leveraging a dynamic language based on the JVM.

In the end I chose to take the dive into Grails and Groovy.  This blog will follow my explorations, challenges, missteps, and (hopefully) successes.

Cheers,
Rich