Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Migrating a Rails app to Grails

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

Posted in Java at Jan 22 2008, 09:37:49 AM MST 12 Comments

Hey Matt,
I've gone through the same selection process. I was actually considering Trails/Grails....I recognize some scalability issues with grails. First you have the fact it is not programmed in Java, but in Groovy, this is a +/- depending on how you look at it. Regardless, it means there is an interpetation layer. Sure, this is compiling to Java classes under the hood....So this should mean that performance should match a normal Java EE system. I read a benchmark that was done by a few Sun Engineers, apparently JEE still is much faster under high load than grails, but grails was much faster than rails. I don't believe scalability will be an issue. Grails is still below a final 1.0 release(rc3?).....

That being said, the thing I like about grails is that it is a best of breed architecture, built around spring and nhibernate. I have seen examples where folks have used grails to quickly build the front end/early version, then replaced the back end with EJB components....Both EJB3 entity beans and session beans.....

So here your removing the Nhibernate code generated by Grails....So the code that is running is as performant as you write it.....You could also just write plain Nhibernate code.....Grails gives you the ability/option to make changes in the architecture to better handle the tough cases. To me grails seems a great way to build a greenfield project and as the project matures, bring in more robust code/components to help you meet the challenges....

I always like to think of scalability as a problem you have to earn, not one you have starting out....Rails I'm not much a fan on, however Grails seems to make me feel alot more comfortable....

Trails brings with it the huge learning curve of Tapestry. Tapestry seems to be very unstable between versions, requiring rework between versions. So in this instance Grails won over trails for my needs.....


Posted by Daniel Honig on January 22, 2008 at 11:57 AM MST #

Very nice. I am looking forward to the follow-ups of this entry.

I would like to propose having a look at the variety of Grails Plugins while doing your examination. The sheer simplicity of e.g. the "Searchable Plugin" (although there is a bug with it in current Grails RC) ist just astonishing and amazes me again and again. It is like the best, battle-proven and robust technologies - in thise case Lucene/Compass for full text search - of the java landscape put together in a highly integrated productive framework.

After having wasted hours of my like with waiting for Ant to rebuild/deploy my Java/EJB/Spring/whatever app and having frustrated with hundreds of "MaxPermGen" Errors from Tomcat and JBoss, it is so refreshing to FINALLY have hot deployment and fast, productive, interactive development at hand.

All of that and the beauty of Groovy - aka executable Pseudo-Code - just makes me as big of a Grails fanboy as it could be.

All of the smart readers of this blog: If you are frustrated with your current development-cycle, have a look at (the holy) Grails. The Search is finally over.

Posted by Sakuraba on January 22, 2008 at 12:42 PM MST #

Daniel, a minor correction, Grails uses Groovy & Java but it is not mainly coded in Groovy, in fact the codebase is more like 70% Java right now. Groovy is used where it gives the best option to the end developer, you. It functions as a glue language between all Grails artifacts but the code under the covers in mainly Java.

Posted by Andres Almiray on January 22, 2008 at 01:04 PM MST #

It only makes sense to use Groovy (dynamic with Java-like syntax) and not Java to build a Rails clone. The big advantage of RoR isn't the framework - it's the language Ruby. I program both Java and Rails/Ruby applications and I prefer Ruby as a language. It's faster to develop and produces less lines of code (and is IMHO much more elegant).

Posted by Lars Fischer on January 22, 2008 at 01:58 PM MST #

Wouldn't it be an easier path to take an existing Rails application and run it on JRuby? With tools such as Goldspike and Warbler, running Rails in a war file is as easy to build and deploy as a Grails application (or any other Java web application, for that matter).

Granted, the Spring/Hibernate connections are not as well-greased in JRuby/Rails as they may be with Grails, but that doesn't mean it isn't possible (or even difficult). Tools like ActiveHibernate are hinting in that direction, and just need more community direction and maturity.

We haven't seen many Rails/Java-backend hybrid applications, because most of them are behind closed doors, just as you point out.

Posted by Nick Sieger on January 22, 2008 at 02:22 PM MST #

I've been playing around with Grails lately. I have a very large Appfuse project that I thought could benefit from using Grails. Appfuse and Grails have different build systems and very different approaches to solving problem so the integration of one with the other seemed difficult. After a few attempts at moving some of my Appfuse code into the Grails build system, fiddling with Gant scripts and so forth, I decided the most clean solution to the whole problem was to use remoting.

Besides being a nice clean layer separating tiers, remoting also adds the benefit of easy scalability in the future as I can quickly add more app servers as needed behind the Grails web tier. So I setup Hessian Remoting in Grails which works great. I then setup Hessian Remoting in Appfuse which works well except for HIbernate objects not playing well with Remoting (LazyLoadingExceptions, class enhancement, etc). This can be gotten around with DTOs and/or playing around with Hessian Serialization or by switching to Ibatis or possibly trying a different remoting protocol. I decided to switch to Ibatis because I looked over the documentation and found it appealing, even though I've been using Hibernate for quite a while now. Anyway, this might be an avenue to pursue as far as integrating Grails into Appfuse in the future. I have a task in Appfuse now that builds all the classes needed for the remoting client and drops it in the grails lib dir. I'll be posting ocassional updates on my blog as the long slog through the land of Ibatis, Hessian and Grails continues...

Posted by Justin Sher on January 22, 2008 at 03:16 PM MST #

Anders, I am aware that most of the code for Grails is java based. However in terms of the code that the developer is writing the application code between parts of the model-view-controller, this is Groovy script. So this is the layer where the "application" is being written, so essentially your application is being written in Groovy. This brings in issues with skillsets on teams, etc....You have to ramp up a bit on groovy before you can write code at peak velocity. Thanks for the clarification though.....

Posted by DanielHonig on January 22, 2008 at 04:14 PM MST #

Agreed, even though Groovy's syntax is very close to Java's some teams may find it a bit difficult to bootstrap their own projects. Fortunately the tools are arriving, it has been mentioned before, IDEA has the best Groovy/Grails support so far, the Eclipse team is also working on giving a great level of support. The peak velocity argument may also be true for teams that do not know Tapestry and chose Trails (or even Sails) as they framework. Hopefully we will see a wider adoption of Grails/Groovy in the coming months so that teams may be able to pick up these tools quickly and start being productive in a short time.

Posted by Andres Almiray on January 22, 2008 at 05:26 PM MST #

Can you tell us more about the Rails apps you want to migrate, Matt? I'm especially interested in the way you build multi-page wizards in Grails. Is it now possible to store domain objects in a session (GRAILS-978 is still open) or, even better, a conversation scope and reattach to a persistence context at the next use?

Posted by Nils Kassube on January 23, 2008 at 02:43 PM MST #

I thought they integrated Spring Webflow a long time ago. But I am not sure whether that is the true answer to your question.

Posted by Sakuraba on January 24, 2008 at 12:31 AM MST #

Yes, Grails now has a very nice integration of WebFlow. You can even build stateful services now.

Posted by Nils Kassube on January 24, 2008 at 02:42 AM MST #

A little late in the day, but I've just finished my first attempt at using Grails by reproducing a very simple photo album that I used as a teaching exercise in Ruby on Rails. Although the philosophy is similar, the devil lies in the details. Nonetheless, I found Grails to be a shallow learning curve, and the reference documentation is superb.

Posted by John Leach on March 25, 2008 at 04:24 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed