SpringSource (now VMWare) has two very similar technologies: Grails and Spring Roo. I have been using Grails, but I see that SpringSource is actively working on something that is a competitor for that technology and that makes me worried about the future of Grails.
Does anyone know how these technologies relate, are they going to be merged, or one of them will be abandoned?
Besides, are there any important technical differences betweent Grails and Roo?
SpringSource's goal is to make it as fast and easy as possible for people to build, run and manage Spring-based solutions. We have both Grails and Spring Roo because we deeply care about developer productivity and unquestionably both of these tools deliver a serious boost to what teams can achieve on top of Spring.
We have both technologies because Roo and Grails are very different at philosophical and implementation levels (as already noted in the other replies). Each technology approaches its primary language (Java or Groovy) and operating model (dev-time or runtime) with the philosophy of "how do we make the value proposition unbelievably good using this language and operating model combination?". As such you'll see each technology adopting a different style that maximises that combination (Roo's Java+Dev-time or Grail's Groovy+Runtime) and the commensurate benefits.
These differences are actually very positive, because they mean the Spring community can chose which "flavour" of productivity solution they prefer. While these initial differences around language choice and runtime/dev-time operation are immediately apparent, the choice of Grails or Roo also extends to more subtle considerations such as the default technologies used, user interaction model, IDE support, dependencies, standards, roadmap, extensions etc. Nearly all of these differences are a natural consequence of pursuing a best-of-breed solution for a particular language style.
Our best advice is to consider both solutions. Each have their sweet spots, but there are differences between the two which will make your overall experience better with one technology or the other in a given context. Both reference guides detail the respective benefits of each solution. Of course, remember the time investment is minimal in trying both out. In 10 minutes you can build a project in Roo or Grails, so give them a try and see what feels more natural for you given your specific background and project needs.
The main difference is that Roo is a pure Java framework whereas Grails leverages Groovy as well as Java. Both are built on the core Spring libraries and make use of popular Java open source libraries.
This question was asked back when Roo was announced and Graeme Rocher (Grails lead) says that both frameworks have a place within Spring and are supported equally.
If anything, I think Grails has a brighter future than Roo. I love developing with it and don't see any downsides to it not being pure Java.
Grails and Roo are very different. The first major difference is the language used. While you can write Groovy code like traditional Java code you still need the Groovy dependencies to run Grails applications. To be as productive as possible in Grails you also need to have a grasp of features in Groovy that are not currently part of Java such as Closures. Another difference is the philosophy the frameworks take to generating code. Grails generates a lot of methods at runtime while Roo generates them on request during the development process. Roo has no behind the scenes magic accept for the usage of aspect oriented programming, and you can view all the code that Roo generates. For example in Roo you must use a command to have it generate dynamic finder methods such as findByBook() and then view the generated code in the .aj files. In Grails the findByBook() method is created at runtime, and you can’t view the generated code. Roo also allows you to stop using the framework if you chose while continuing to have a running application by merging all the generated code into normal .java files. You then have no dependencies on any Roo libraries at either runtime or design time. If you decide you don’t like Grails there’s no way to stop using the framework while continuing to have a functioning application.
IMO the two are not very similar. Even though there are similarities the following are significant differences:
Roo uses "Stock-Standard Java",
Grails is based on Groovy
Grails is a Web framework, Roo is not
Roo is very similar to Grails' command line system (e.g. the create-app, create-domain-class, test-app type commands found in Grails). I would not be surprised to see some "cross-pollination" between this part of the Grails framework and Roo.
Ben Alex from SpringSource talks about Roo in this interview and he is asked about Grails vs Roo. The main difference besides using different languages (Groovy vs Java as others mentioned) is that Roo is mainly a development time tool and Grails is more involved in runtime.
They're actually not that similar. Roo does it's magic at compile time, where Grails is does it runtime. Because of that Roo projects does not take any performance hits at runtime.
I can't see how they could be merged as Grails is built upon Groovy and Roo on Java.
I saw some comments on the Grails mailing lists which indicated that the authors believed that Roo exists only as a stepping-stone to Grails! However I am personally considering a possible switch from Grails to Roo. I think the main difference is between dynamic and statically typed languages - to me this is huge. I love many features of Grails but I prefer the IDE support and compile-time checking of a statically typed language. Some others feel exactly the opposite, hence horses for courses. That said, static groovy is currently under heavy development so who knows what the future holds.
We had a requirement where we had an application in production and was developed in Spring MVC and the velocity of developing new features were slow. We had to explore alternate frameworks like Grails and Roo. I personally spent close to a month exploring which one was better.
If you want to see the details of the analysis visit # http://krishnasblog.com/2012/05/08/roo-vs-grails/
We explored following features in both these and below is our findings. The final verdict we are not sure we will use either one, we are still exploring
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I know that there have been plenty of topics describing this topic but I still can't put up my mind what to choose.First of all, I need you to know that I am a student in his last year, who will probably continue studying for a few years. However, I'm trying to find what I would benefit most from.
I've been in contact with RoR last year; seeing Ruby's squirky syntax amazed me, and Rails CoC and DRY principles make me dream. I've written some scripts to generate sql statements in Ruby, but that is about all.
I'm considered to be a java developer, as they call me the java guy on school, (no, i do not consider myself good, on the contrary, every day I realise more how much more i've got to learn). Now, I've taught myself several technologies related to java. To make my work easier, I opted learning hibernate and maven. Now we are developping an application in Spring + Spring MVC.
Grails caught my attention lately since it is built on top of these technologies, and uses a language that is similar to java, and allows access to java classes.
However, i'm not sure what is the best way to go. Should I struggle through Ruby's quirkyness first, and learn Rails? Or would learning Grails first give me an advantage over learning RoR?
Also, as far as from what i've read, RoR would give me a bigger advantage on the market than grails would; but how do I get a "proof" that I can use RoR? Would it be enough to be able to show applications made using RoR?
I've used both frameworks pretty extensively, and both have their warts and advantages, but when you come right down to it, there aren't that many differences for someone coming from your background.
In my area (Minneapolis), the grails market is larger than the rails market, but that isn't the case everywhere.
I'd pick whichever one has the user group in your area that you connect with the most. That will be your best bet for finding work with whichever one you choose.
You've mentioned that you're already into Java, Spring and Hibernate. Well, Grails is based on those - in continuation.
Spring is a very comprehensive, powerful, and modular, framework. Hibernate has been a de-facto standard, and is compliant with Java EE 6's JPA. Both are most relevant in the Java world.
So, there's the aspect of consistency of your technical knowledge. From Spring/Hibernate to Grails/GORM you'll have cohesive knowledge.
Another central aspect is your options. When dealing with Spring, you'll probably soon learn how easy it is to change complete architectural layers, like, changing the view technology, or database layer, or simply exporting a web service by configuration. Spring-based applications can be highly modular, and you can plug-in almost any technology scope you could think of. - So you have many ways to go further if desired.
The Spring framework has been written from the ground to foster best practices. Just dealing with that framework will teach you a lot.
Admittedly, I haven't dealt with Ruby on Rails, at all. I regard it a rather isolated technology, while Grails is a (Java and Spring) integration framework to me, with the backends/grounds and options as mentioned above.
When evaluating practical aspects of technologies, it's always a good idea to do some research on Google Trends and Indeed job trends. Other indicators on popularity/relevance are the numbers (and trends) of mailing list messages for Grails vs. Ruby on Rails, and (not quite an accurate measurement for niche languages) the TIOBE programming languages index.
Finally, Java had experienced several years of starvation and uncertainty in the past (despite of being one of the few all-time languages and frameworks, at all, and a long-burner). Recently, however, several evident signs came up that appear to seriously forecast a much brighter future than before.
As a Grails developer...
Grails runs on mature and proven virtual machine (JVM) and really do the best performance compared to any dynamic language, even static Java/JSP when using Freemarker Plugin! http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/
Grails uses Groovy, so it has an almost flat learning curve for Java developers. You can write Java syntax and gradually learning Groovy syntax, closures, meta-programming and more... getting expressiveness and agility of a dynamic language like Ruby.
Grails uses modern principles and practices like Convention over Configuration and Scaffolding, just like Rails taught us all.
Grails uses a mature platform, so it comes w/ all great existing java libs, mature groups and projects like Apache, Eclipse, JBoss and so on for reporting, file exporting, legacy integration... and many new well-supported libs and frameworks from Google and others like Guice, Guava, Collections and so on...
Grails uses a vastly used platform, so you can reuse all your existing java libs. You could reuse your entities, utilities, and so on...
Grails use existing Java infrastructure, so it comes with many ready & mature server w/ great documentation (i.e install, configuration) Tomcat, Jetty, Glassfish, and so on...
Grails use existing Java infrastructure, so it scales very well w/ many ready & mature options: Server Clustering, Open Terracotta, Second Level Cache, and so on...
Grails runs on top of well-know and vastly documented frameworks like Hibernate, Spring MVC, Hibernate, SiteMesh, and so on... and you can step down into abstraction when you need, i.e batch imports, complex reporting queries, complex interfaces, and so on..
Grails has a great plugin ecossystem much like Ruby Gems and can use all existing Maven-based lib repositories to resolve dependencies.
Grails uses a solid platform, so you'll always reuse your libs (JARs) with the next Language of The Year (LOTY). "Write Once, Run Ever"
Hope that helps! :-)
If you liked Ruby's syntax and simplicity, go with Rails, and run it on top of JRuby, which will give you access to Java classes as well.
Check: http://blogs.oracle.com/coolstuff/entry/using_java_classes_in_jruby
I'm coming across references to 'Grails' and 'Groovy' quite often these days.. mostly on how great a productivity booster it is as opposed to standard Java EE, or things like JSF, Struts etc.. And there's also an impressive set of case studies in support of this on their web site too. So I just thought I would explore some of it..
As I start off on this, I was curious if there was any material (link, blog, article, paper..) that explains what are the special features in Grails+Groovy (and not found elsewhere, in the Java EE world) that makes it a more productive environment to work in?
The Wikipedia Grails page provides a basic explanation:
Grails has three properties which attempt to increase productivity when compared to traditional Java web frameworks:
No XML configuration
Ready-to-use development environment
Functionality available through mixins
The first point should really be "less configuration" as a result of RoR-popularized configuration-by-convention: the framework addresses development of a certain class of applications and provides sensible defaults in that context.
The second point is also valuable: a hello world application can be both developed and deployed in a couple of grails commands. This reduces the barrier to entry, increases mind-share and makes for a more streamlined development experience compared to pure Java development.
I'll use an example from the Grails GORM page to illustrate the 3rd point. Grails allows you to write this kind of code to retrieve a book by its title from the "book" table without having to set much of anything up:
Book.findByTitle("Groovy in Action")
Of course, it's the result of a much more general property of Groovy: its dynamic nature.
For more practical productivity increase reports, see e.g. the Sky report.
A framework becomes useful when it minimize effort to do something. That's why C became more successful than Assembly, C++ improved on C, and Java on C++.
Although not strictly listed in pro and cons, I like the discussion of the subject in a blogpost by one of the early Groovy developers. Furthermore, I also like the discussion on another modern database-backed-webapplication framework by Martin Fowler, one of the leading architects in the Java EE world.
I also came across Groovy first, while testing Java applications. You will come in touch with work of Dirk Koenig, e.g.short Groovy presentation.
By the way, if you want to develop "cloud" related applications, then Ruby opens up a bunch of doors as well.
Nowadays I hear a lot about "Groovy on Grails" and I want to know more about it:
What is Groovy?
What is Grails?
What kind of applications are built using Groovy on Grails?
What is Groovy on Grails?
It doesn't exist under this name anymore. It's simply called Grails now.
What is Groovy?
Originally, a dynamic language for the JVM. However, since Groovy 2.0, both static and dynamic typing are supported.
What is Grails?
Grails (previously known as "Groovy on Grails") is a programming framework based on Groovy and inspired by Ruby on Rails (there are differences, but there are lots of similarities too). Like RoR, Grails promotes "coding by convention", development best practices, and is meant to be highly productive.
What kind of Applications are built using "Groovy on Grails"?
Grails is used to build web applications that run on the JVM.
What are the advantages of Groovy on Grails?
High productivity, focusing on business instead of plumbing. (Note that I wouldn't recommend to use Grails with an existing data model. The reason behind this is that Grails encourages a top-down approach where the databases ER model arises as result of the Domain classes. If you are using a legacy database, you cannot take this approach. You must map the database to the domain classes, and probably the naming convention won't match, making necessary the use of hbm.xml Hibernate configuration files or annotations. IMO, this is not a trivial change in the workflow, it can become really cumbersome and you end up losing most of the advantages of Grails.)
Why would one want to use Groovy on Grails when we have standard programming languages like C/C++, Java/J2EE, and .NET/C#?
Because of point 5.
Groovy is an object-oriented programming language for the Java platform. It is a dynamic language with features similar to those of Python, Ruby, Perl, and Smalltalk. It can be used as a scripting language for the Java Platform. Groovy has a Java-like syntax and works seamlessly with Java bytecode.
Other features include:
Easy learning curve
Support for domain-specific languages
Compact syntax
Support for dynamic typing
Powerful processing primitives
Ease of Web application development
Support for unit testing.
Grails is an open source web application framework which uses the Groovy programming language. It is intended to be a high-productivity framework by following the "coding by convention" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer.
Like Rails, Grails seems to be what I call "Strongly Grained". If you do things the Grails way, development is easy (and generally quite fast). The framework tends to have a preferred way of doing most things. On the other hand, if you need to go against the grain, you'll have a comparably rough time of it.
And don't say Groovy on Grails(doesn't exist), for reasons refer to this blog.
Grails is directly analogous to Ruby on Rails, but running with Groovy. What's Groovy ? It's a scripting language that runs on the Java Virtual Machine (JVM).
So you can make use of Java libraries that you already have or are available (since they're compiled to bytecode and thus run on a JVM), plus the power of the JVM (for garbage collection, speed via JIT compilation etc.) and the conciseness of Groovy. The learning curve for a Java programmer to pick up Groovy is supposed to be pretty small (thus leveraging off the huge number of available Java programmers).
It's a very different way of creating web apps to the standard Java mechanisms of servlet programming, JSPs, Java Server Faces etc. Grails (like Ruby on Rails) promises a more dynamic and iterative development environment than the standard development mechanisms (whether that's true in practise, I can't advise)
Grails- MVC framework for developing a web application and a ready to code platform with DRY (Don't repeat yourself) built on the top of Spring+Hibernate. Grails platform takes care of the infrastructure and dependencies to run a web app such that the developers can concentrate on building the functionalities for the product. Grails -a great framework for the startup organizations to launch the product from the development mode to production mode.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Grails vs Rails. Which has better support? And which one is a better choice to develop medium size apps with? Most importantly which one has more plug-ins?
One other thing worth mentioning: the design philosophy of both framework is somewhat different when it comes to the model. Grails is more "domain-oriented" while Rails is more "database-oriented".
In Rails, you essentially start by defining your tables (with field names and their specifics). Then ActiveRecord will map them to Ruby classes or models.
In Grails, it's the reverse: you start by defining your models (Groovy classes) and when you hit run, GORM (Grails ActiveRecord equivalent) will create the related database and tables (or update them). Which may also be why you don't have the concept of 'migrations' in Grails (although I think it will come in some future release).
I don't know if one is better than the other. I guess it depends on your context.
This being said, I'm still myself wondering which one to choose. As Tom was saying, if you're dependent on Java you can still go for JRuby - so Java reuse shouldn't be your sole criterion.
I guess if you are a Java developer and want to have access to all the existing enterprise Java libraries and functionality... go with Grails.
Rails is more mature, has more plugins, has a bigger userbase, has better documentation and support available. It can also run on JRuby giving access to Java libraries if you require.
Grails has some interesting qualities, but can't claim to be up there with rails just yet. However, if you're predominantly a Java or groovy developer you may prefer it. Otherwise though, I'd suggest using Rails for medium sized projects right now.
I say grails since there are so many java libraries out there. But I am a bit biased due to the fact that I come from a java background.
If the app isn't going to be big, either suffices - and the choice ought to depend on existing infrastructure. Say if you already have a java servlet container server running, you might as well stick with grails instead of provisioning another server for rails.
I used rails before and liked it quite a bit. However, my current company had a lot of legacy java code and therefore the natural choice was grails.
When I started with rails, very few sites were using it and documentation was atrocious. There was railscast that was great and railsforum.com, but anything out of the ordinary, you're on your own. Deploying it was a nightmare, and using mongrel-clusters was not really production ready. This is very different now as everybody can see, much more mature and deployed everywhere.
Over a year back, I had to learn grails due to reason I cited above. Transitioning to grails was very easy, since it is very similar to Rails. Again, it was very similar to the early stages of rails, with one huge difference. Because you can easily import java code, grails users can use almost all the production tested java libraries available out there. I've been able to successfully integrate our legacy java projects into grails projects and very little tweaking are needed. You will also notice that plugin development has been rapid, mainly because developers are just writing grails "hooks" but the underlying code are the old java libraries. Deploying grails is also just deploying a WAR file.
Another thing you have to look at is IDE. If you're comfortable with eclipse, then eclipse-STS for grails gives you all the bells and whistles. I still see a lot of rails developers use textmate, though rubymine has made great strides (the early version of rubymine used to grind my ubuntu to a halt).
The bottom line, both are great MVC frameworks. RoR is much more mature and has a lot more developers. Grails is where RoR was 3-4 years ago, but I see the progress a lot more faster. Hope this helps.
It depends on your skills with Ruby and/or Groovy, whether you have legacy Java systems to deal with, and where you want to deploy your applications.
I was initially thrilled with Rails. At the time, there wasn't an option of deploying on the application servers at work since work is all Java. This has changed. I couldn't abandon the Java infrastructure and applications already in place and switch to Ruby, even though I thought Rails was awesome. Grails works because we can mix and match Groovy with the existing Java solutions.
Outside of work, Ruby is easier to find hosting for at the low end of the price spectrum. Because Grails uses a lot of existing Java projects the .war files, even for a small app, tend to be large. If you have a dedicated server this isn't a problem but trying to run on shared hosting with 128 MB RAM doesn't work.
2008 is the year of Groovy and Grails books but there are still many more Rails resources available.
Based on your specific criteria, Rails may be a better framework to learn. If you have any Java knowledge, or baggage ;-), you should look at Grails.
Seeing as how the guys who make Grails just got bought out by Spring source yesterday, I would say Grails.
Also, since Groovy is a superset of Java, you can dive right in just using the Java you know without having to learn Ruby. Now, you'll learn a lot of dynamic stuff too and eventually write Groovy code instead of Java code, but it lowers the barrier to entry.
Grails all the way!
I would go with Grails since I like its approach (specify your domain classes and have Grails generate everything else) better than the Rails one (build database tables and have Rails generate everything else). If you're a Java developer, you'll also like that Java code is valid Groovy code, and a Groovy class is a Java class so the integration is seamless both ways.
As a Grails developer coming from Java, I loved it from the very first time.
Now, I'm starting to dig into Rails and having problems with gem. While MySQL connection setup with Grails was pretty straightforward, I'm still struggling to make it work with Rails.
The command gem install mysql is not working, apparently because I don't have XCode intalled.
If it weren't for its memory consumption issue, I'd say Grails is perfect.
May I suggest Merb? It is rack-based, modular, ORM-agnostic, built for speed from ground up by Ezra Zygmuntowicz. It is starting to gain some heat now...
Rails is more mainstream, but less flexible. Grails is still changing rapidly, doesn't have the same developer ecosystem, and the documentation isn't nearly as mature, but it will work in some situations Rails won't.
I have used turbogears and rails a little bit. Before using rails, I tried using grails because I was using groovy for my scripting. Grails was a difficult experience.
The groovy call stack is difficult to read for a small program, but when you add in several heavy weight frameworks a simple error can yield 100s of lines. Unlike rails the grails version that I was using didn't have tools to help me determine what was mine and what belonged to the framework.
I eventually switched to using the Google Web toolkit since I really didn't need the database.
I think Grails and Groovy hold promise, but the user experience of working with them is cumbersome at present (present being last spring).
I think it depends on the environment you're working in to some extent.
Grails seems to have more corporate level acceptance.
Rails has the Koolaid-vibe, and is very acceptable for start-ups with no legacy systems.
Personally I'm using both. Though only really just starting out in the Grails world - I like that authentication/authorisation is easier in Grails-one simple plugin; Shiro. I like that Rails isn't dependant on JVM, and doesn't take a minute or so to startup.
I find setting up BDD/Cucumber within Rails was far easier, but that could just be because that's what I'm comfortable with! There's definitely efforts in the Grails world (cuke4duke etc) to make this easier-and an active community developing Grails.
Just my 2p·
Try both :)
My company is in the process of starting down the Grails path. The reason for that is that the current developers are heavy on Java but felt the need for a MVC-style language for some future web development projects. Personally, I'm coming from the design/usability world, but as I take more "front-end" responsibilities I'm starting to feel the need for learning a language more intensively so I can code some logic but especially the front-end code for my UIs and stuff.
I've been trying to get into Python/Django personally, but just never invested too much time on it. Now that my company is "jumping" into Grails I bought the "Agile Web Development with Rails (3rd Ed - Beta)" and I'm starting to get into RoR. I'd still like to learn Python in the future or on the side, but my biggest question is:
Should I be learning RoR, and have a more versatile language in my "portfolio", knowing that my RoR knowledge will be useful for my Grails needs as well??
-OR-
Should I just skip RoR and focus on learning Grails that I'll be needing for work soon, and work on learning RoR/Django (Ruby/Python) later?
Basically the question revolves around the usefulness of Grails in a non-corporate setting and the similarities between Rails and Grails. (and this, while trying to avoid the centennial discussion of Python vs Ruby (on Rails) :))
Mmh, I don't know how to say this. Some people might bash me over this.
Language (Groovy and Ruby)
As a language I reckon Ruby is more funky compared to Groovy. Groovy only exists to ease Java programmer as you don't need to learn too much new syntax. But overall I reckon is not as funky as Ruby. Groovy wouldn't be the JVM language that is worth to learn based on attender's vote in this year's JavaOne but instead Scala is the one to go. Besides that, the original creator of Groovy himself does not have faith in the language he created himself in the first place.
Community and Job openings
As for the community, Grails community is not as big as Rails, though since the acquirement by Spring more and more people are using it in serious application. Rails has more job openings in the market compared to Grails (that is if you want to invest in looking a new job).
The framework (Grails and Rails)
But, as a framework, if you really care about maintainability and need access to Java framework and legacy Java system, Grails is the way to go as it provides cleaner access to Java. Grails itself is built upon several popular Java framework (Spring & Hibernate). Rails itself IMHO is funky like Ruby itself, but it's funkyness costs you maintainability. Matz himself prefers Merb over Rails 2 because Rails create a DSL on top of Ruby which is really against the Ruby philosophy. And I reckon because Rails itself is opiniated, which in turn if you don't have the same opinion as the creator, it might not fit your needs.
Conclusion
So in your case, learn Grails as that is the company's consensus (you need to respect the consensus) and if you still want to secure your job. But, invest some time learning Rails and Ruby too if you want to open a chance getting a new job in the future.
Just a bit of a question, is the reason they are choosing Grails because Groovy is closer in syntax to Java than Ruby, or because they want access to Java?
If it is the former, then I would say try to focus on Grails since that is what you will be using. If it is the latter, you might want to see if the development team is open to using JRuby.
I have never used Grails or Rails before, but I have used Groovy and Ruby before, and as a language I think Ruby is much cleaner and more consistent, and the team might enjoy production more. As a platform, Rails has been out longer and has a lot of attention, so I would imagine it is a more stable platform to use with more fleshed out features.
JRuby has full access to classes written in Java, so this is why I would say consider trying Rails. If it is too late in the decision time to consider it then I guess you can just ignore this post.
Basically, if you just want to hook in with Java, then JRuby is an option you should consider, but if the team is afraid of non-Java like syntax, maybe continue as is.
I would learn both. They are both up and coming technologies. Learning RESTful coding is a real benefit in any language.
I use GRAILS at work and RoR for side projects. I can say that the RoR community is much larger (I'm talking about RoR vs Grails not RoR vs Java) and very helpful.
Short Answer: They are similar.... what could it hurt?
Just skip RoR. There are really not a lot of similar things(besides the name)
I certainly believe that being enough familiar with Java, plus some experience programming with a dynamic language is more than enough if you plan to do serious development with Grails.
Comparing just only views(taglibs in Grails, RHTML in RoR) and the persistence stuff(GORM vs ActiveRecord) is just too different in the core, to invest time learning the nitty gritty details of RoR. Just dive into Grails, you won't regret.
Edit: corrected typo.
I've been learning RoR and Grails and the latter is far easier to learn.
Both frameworks share the same principles (agile, kiss, dry, duck typing and so..) but Groovy syntax is...well is simply great, something you can learn and use in a blink of an eye.
I truly feel that Grails has brighter future than RoR.
PD: Just in case you find it useful, a college of mine it's working full time with Grails and has a blog with some tips:
http://dahernan.net/search/label/grails
You should just skip RoR and focus on learning Grails that you'll be needing for work.
#Levi Figueira
For one thing, Grails is far more flexible than Rails. Rails is difficult to use with a legacy DB because ActiveRecord has too many design constraints that many legacy DBs didn't follow. Grails, oth, can use standard Hibernate mappings, which can accommodate a much broader range of DB designs.
The Rails community has been very vocal in evangelising RoR, with the result that high expectations have been set and not always met (programmer productivity is good, but ensuring good performance once deployed isn't so easy).
Grails has been designed as the scripted successor to Java, whereas the Ruby-Java integration used in JRuby on Rails, for example, has had to be retrofitted.
I would suggest that you stick with Grails; it may not have the same glitz as RoR, but it's a pragmatic choice; you get improved productivity and the re-use of existing Java libraries.
Jump straight into Grails. I'm sure Ruby/Rails is good but so in Groovy/Grails. I recommend this book.
http://beginninggroovyandgrails.com
Remember the errata is online. There are a couple of mistakes in the book.
http://beginninggroovyandgrails.com/site/content/errata
Also, check out the 3 minute and 30 second demo of creating your first Grails app.
http://grails.org/Grails+Screencasts
This tutorial will show you the basics.
http://grails.org/Quick+Start
Yes Grails is the way to go. RoR is good but it ties you in to the Ruby ecosystem. Part of the effort of learning a new framework or language is learning the class libraries as well as the language syntax. If your co-workers are all Java types you will be much better placed to receive help and support as they will all be speaking the same language as you.
The other advantage to learning a bit of Groovy and Java is that web frameworks like GWT will open up to you. Grails has a GWT plugin and as a front end developer you will appreciate the ease of use and cross browser compatibility.
Also there is at least one hosting company offering free Grails application hosting (http://www.mor.ph/) which means that you can prototype sites at small data volumes before having to pay.
I favor Grails over Rails, but learning Rails will give you a more balanced perspective and actually open your eyes to overlooked things that are possible in Grails.
At a first glance you would think they are completely differente stories, since they are based on extremely different languages (Ruby and Groovy).
Then, after reading a couple of tutorials, you'll realize they share the same principles, scaffolding, duck typing, .. and finally the same goal:
making agile programming feasible.
If you already feel comfortable with terms like IoC and MVC, you'll find any of these options easy and exciting to learn.
I would say no, I'm learning Grails as well, and I've considered this as well, but just learning Grails is pretty big, plus learning Groovy (which granted is easy, but still gotta learn it right?) and all that... so learning Rails would have been just too much.
Yes if we compare grails and rails I would choose grails (I developed some intranet applications in grails).
But Django is superior to both - as python is well hmm a perfect choice.
You might also want to take a look at Clojure, a JVM language that's just starting to get popular. It may be a good choice for a Java-based company since it's compatible with your old codebase, and has a lot of modern innovations going for it. There are some good web frameworks emerging, including Compojure.