[quote]
It would have been nice if I could have told him that he could develop in Ruby on Rails and still know that he'd be able to seamlessly integrate with the J2EE platform, but JRuby really isn't ready yet.
[/quote]

Know what _does_ fully integrate with J2EE and allow rapid prototyping?? Groovy + Grails. It was meant from the start to integrate with the Java platform, and all its associated standards and APIs. If you're already on the JVM, this is _the_ way to go.

[quote]
...and I'd like to be able to start integrating a Rails MVC front-end with the Spring Framework.
[/qoute]

Done. In Grails. NO re-inventing the wheel or duplicate-API syndrome from the Rails dependencies.

Groovy on Grails has *NOTHING* to do with Ruby on Rails. It is a similar "idea", but it doesn't really have much to do with anything that came out of DHH or 37Signals. As such, it doesn't really have a huge community.

On one hand you have a wealth of ideasin the Ruby on Rails world, plugins for everything from full text searching to video processing. Acts_as plugins that allow you to do something like make a model available in a full text index with as little as a single line. Literally thousands of eyeballs at the user level with blogs and blogs out there to help you figure things out. Not just one or two books (like Maven :-) ), but a series of books about Ruby and Rails written fro differening perspectives.

To say, "Why would we ever want Ruby on Rails integrated with the JVM when we've got Groovy on Grails" is ignoring the fact that Groovy on Grails is a failed derivative of Ruby on Rails written in Java. If you really wanted to use something that was Rail-ish on Java, you'd probably start with Rife.

The only reason Grails doesn't have the same capability is because it doesn't have the hype -> developer community that Ruby + Rails has. You're right -- Grails (rightfully) doesnt have the Ruby+Rails community's attention, but it _should_ have the Java community's attention. (This is OnJava, not OnRuby :-)

But if they were to add full-text searching to Grails, it would probably be done using Lucene (again, a well established Java framework) rather than being done in Ruby and then run on top of JRuby.

Point is, the Ruby and Rails stuff is awesome, but doesn't fit as well in the Java environment as a scripting language and framework that was _meant_ to run in the Java environment. Neither Groovy nor Grails are 'failed,' they are simply less mature and could be just as capable (and more interoperable) given the support.

Also, I apologise for the rude tone of my first post.

@Tom
"Also, I apologise for the rude tone of my first post."

Hey, no apologizing, there's nothing like a good row especially over this stuff, it at least demonstrates that there are people paying attention. too many people "dancing on Java's grave" these days according to a colleague, at least you feel stringly enough about Java to say, "hey, wait a sec, Groovy on Grails".

But, let me just respond to the last response. When you say, that the only reason Groovy on Grails doesn't have all these features because it doesn't have the hype that surrounds Ruby on Rails, I'd say that's a circular argument. The only reason Groovy on Grails even exists is because of the hype surrounding Ruby on Rails, and then to say that "well grails would have it if we had the hype", just seems to miss the point that people are using Rails because it is good.

And, trust me, I've trolled both java, ruby, and rails forums. The reason Rails is popular isn't hype, it is that Rails provides a really compelling unity of approach to a problem, and the ruby languge itself lends itself to being used as a sort of printing press. by that I mean that you can decorate (inject, mix-in, whatever...) an existing object very easily. The closest we have in Javaland is Spring or AspectJ.

Rails doesn't have full-text searching, there is a plugin that provides fulltext searching, the plugin has nothing to do with the rails project. Same thing with image manipulation, tagging, anti-spam checks, and on and on and on. So it isn't that Groovy needs to add full-text searching and then i'd be done calling it failed, it needs to simplify the framework and provide a better plugin mechanism that encourages a community. Struts has had a plugin mechanism for years now, but I don't see a rich community of Struts plugin developers because the framework didn't lend itself to extension. Groovy on Grails copied Rails, but a railish approach in Java has to look different by definition because Java lacks some of the features of the Ruby language. That's what the Rife comment was meant for - Ruby on Rails already exists in Java, it's called rife, and it's different.

And, I'm not just saying this to be contentious, but I do think that Groovy on Grails is a failure. A Good technology is like a candle in a darkened room. People see a simple idea, if it sells, they flock to it in droves immediately, in the open source Java world, i've seen too many, "If we make it incrementally better they will flock to us arguments". If you look at the adoption curve of successfully technologies like Ant they take off because of something that Rails has "unity of approach".

Okay, well I'm feeling better because it looks like we're converging here... And I have to admit that the "hype" argument is somewhat of a cop-out. I agree that Rails is good and deserves recognition. I feel that Groovy+Grails is extremely capable but doesn't get as much attention because it 'seems' immature (mostly due to sub-par documentation and pre-1.0 version numbers... I seem to remember RoR facing a similar challenge before its popularity boom).

I think that RIFE is limited by the Java language. Yes, the architecture of RIFE aims to avoid those limitations, but you use RIFE by writing Java code. You have to realize that Grails is not a "rails-ish approach in Java," it's a Rails-ish approach in Groovy. As far as I am aware, Groovy is just as capable (in terms of language features) as Ruby. As a result, Grails is not limited by Java at all, but you can still call any java code (say, to Lucene) from your Groovy/Grails code. I wonder how easy it is to make a JRuby/Rails plugin from existing Java code.

As a result, Grails is not so limited because it is written in the Groovy dynamic language. This is key.

Groovy provides the mixin and metaprogramming features that makes an extremely powerful framework like Grails possible, just as Rails would not be possible without the features that Ruby has.

Take for example dynamic methods in Grails:
http://grails.codehaus.org/DomainClass+Dynamic+Methods
See near the bottom, the countBy* and findBy* methods -- This absolutely not possible in Java. This is about as injected & mixed-in as you can get. Not to mention that Groovy has closures, which makes things like validation:
http://grails.codehaus.org/Validation
a breeze.

Again, Ruby and Rails are great, and JRuby is an _awesome_ thing for the Ruby/Rails community. But if you're a Java developer who wants to reuse existing Java code & frameworks in an agile web environment, I think Groovy + Grails in your already standard servlet container, interacting with the EJBs you've already created... Just works.
http://www.infoq.com/articles/grails-ejb-tutorial

Thanks Tim for letting me share my opinion.

A few things I'd add:

1. The fulltext search plugin you're likely referring to is built on top of a port of Lucene to Ruby: Ferret. I attended a session with the developer at RailsConf, and his advice was to still use Java/Lucene for indexing since Ferret isn't fully stable and lags behind Lucene.

2. I think what's behind the success of Rails has everything to do with the fundamental design of Ruby. Ruby is what makes Rails possible. That's what the buzz originates from, I believe.

3. Having said that, for my money, if I'm writing code to integrate a dynamic language with Java, Groovy doesn't show the seams nearly as much as JRuby, or Jython for that matter. That counts for a lot. Groovy is still a runner in this race. The early drafts of the new Groovy in Action book are excellent, and just having that first book should go a long way.

@Ken

You've had problems with Ferret? i guess I haven't run into them yet. Thanks for the tip on creating the indices with lucene. The act_as_ferret thing is just amazing, and the fact that ferret is interoperable with Lucene makes it even better. (IMO, it's easier to configure an Lucene index builder in Java)

@On Ruby being the foundation of Rails...

Ruby might make Rails possible, but there were web applications written in Ruby before the advent of Rails, and Rails is really want has attracted the most attention to Ruby. I believe that there is something special about the design of Rails that can't just be attributed to Ruby, in other words, I don't just think a ruby MVC framework with this much momentum would have sprang up from the primordial goo if it weren't for the "opinionated developer" who created it. (Ditto for Django and Python which is almost as good)

@Groovy not being out of the race...

Agreed, Groovy isn't out of the race at all. I use it, it's useful when it is useful. But, it certainly is a different way of thinking about scripting. i'm not even sure I'd call it a scripting language (ditto for Jython), it sort of sits between worlds, it is a scripting-approach but also heavyily based in Java. for this reason, it isn't very accessible. Actually, it's esoteric compared to something like Ruby - with Groovy you have to make sure that someone is well aware of the JVM, Java syntax, etc. etc., then you have to teach them this "java-lite" language called groovy. By definition, Groovy isn't going to have as large a user base as either Ruby or Java because it requires knowledge of Java.

Getting Ruby to run on the JVM without requiring some hybrid syntax will open up the "Sun VM" to a whole new collection of people, and we won't have to teach them Java first. I use Groovy, but I just odn't see it leading us out of the dark ages

It seems that Eclipse is becoming a Dogma. You have to appreciate that some people don't like it. I desperately wanted to but just can't and I know others who feel the same (especially Mac people - the cross-platform experience is awful). If Sun wants to develop Netbeans good for them - sheesh. As an objectivity note I should say that I don't use Netbeans either (IDEA for me).

My thanks go to Sun for recognizing and paying for a couple dedicated Ruby people. Power to them.

@Chill

"It seems that Eclipse is becoming a Dogma. You have to appreciate that some people don't like it."

Sure, and some people don't like Spring, but very quickly standards emerge and the people shying away from the standards become stubborn curmudgeons clingning to a tool which few pay for and use. Eclipse is emerging as that standard, it is the solid open source option. IDEA is acceptable, but the fact that it even has a price puts it out of the race for most.

Netbeans...well, "Chill", have you ever been to JavaOne? They should call it the "NetBeans roadshow". NetBeans is OK, but if lots of people use Eclipse, and fewer people use IntelliJ, NetBeans lags those two by miles.

Here's the deal Chill, Sun has necessarily proven themselves to be a great "steward" of Java over the years, mainly because instead of simplifying the language and focusing on core technology, they've continued to bundle, bungle, and delay. People are dancing on Java's grave not necessarily because of the language, but because of the snails pace at which VM progress is made.

"My thanks go to Sun for recognizing and paying for a couple dedicated Ruby people. Power to them."

So, no, I'm not a cheerleader for Sun, and I'm not going to just treat this as a Tim Bray pep rally. This might be good news for the people involved (read, we get a full time job), but I can't view this as more than lip service to the Ruby community. JRuby is so compelling these guys deserve to be paid merely for making it work, there is no reason to tie them into the NetBeans effort.

Here, I'll summarize it as follows: "Come work for Sun, you can work for the third place IDE, and during your extra time get JRuby to work"
Right, sure power to them for dragging feet on open sourcing Java. power to them for creating the

"WRONG, has he ever used RadRails, Eclipse, Komodo"

WRONG, otherwise how can they implement Java version Ruby???

Just with notebook XD

"WRONG, has he ever used RadRails, Eclipse, Komodo"

WRONG, otherwise how can they implement Java version Ruby???

Just with VI ??? XD

@Tom - Thanks for sticking up for Groovy/Grails

@Tim -
There is really no need to get into arguments such as these. Ruby on Rails is a great framework, and Ruby a fantastic language, but the thing is not every problem can be solved by Ruby & Rails.

There are a huge amount of organisations that simply can't run and support Rails and Ruby. Their systems are built on Java and their investment is in Java (hardware, software, knowledge etc). At the moment their are efforts to get JRuby on Rails running and that is good, but Java integration goes that little bit further than simply running with the JVM and that is what Groovy and Grails are trying to address.

There is simply no need to use phrases like "Grails is a failed derivative.." as there is space for all kinds of web frameworks that solve all kinds of problems. Can't we just accept that frameworks are their to address issues and provide options to developers?

Groovy and Grails have given options to people and allowed those who are seeking a Rails like environment, but with tight Java integration the option to use it and given how the Grails community is growing every day, that we have an upcoming books on Grails and Groovy and that we have face-to-face training course on the way in London I would hardly call this "failed"

The effect is that Groovy and Grails have buzzing communities. Sure, they're not as large as the Ruby/Rails community, but then if you compare the size of the Ruby community to that of the Java community it is no where near the size in comparison. All things are relative.

--
Graeme Rocher
Grails Project Lead
http://grails.org

@Graeme

IMO the open source community needs to stop giving people credit for just having a project. Grails Dev seems to have stabilized at about 10 threads a month, there a small handful of people involved, but to say that the Grails community is smaller than the Rails community is more than an understatement. But, I do think that Grails is derivative, and that it is chasing a train that can move much faster than can be followed with the limitations of Groovy. If Grails were going to attract that community it would've happened by now.

I'm also convinced that for a Java programmer to learn Ruby vs. learning Groovy. *Maybe* Groovy might be a smaller leap, but scripting concepts are the same. If you elect to use Groovy in an application, you'll have an easier time integrating with Java in the JVM, but you'll have less resources available (books, blogs, community). If you were able to use something like JRuby, (if JRuby had better performance), you could translate any scripting you wrote outside of an environment that has a JVM, and for people looking to automate without always having to roll out the JVM, this is a big winner.

I use Groovy now and then, it is interesting, but I'm looking for something else. That's just my own taste, and I'm not going to hold back on this blog. For some reason, it's something of a sin to express an opinion in the open source Java world.

I'm just curious... What are the "limitations of Groovy?"

@Anonymous,

"What are the limitations of Groovy?"

1. It's a confusing Java/scripting language hybrid. One of the reasons you side with a scripting language for some tasks is that it is reportedly easier for people to pick up on something like Ruby versus something like Java. And, from the people I've worked with, I'll attest to the fact that it is much easier for someone to break into Ruby programming versus Java programming.

2. Portability - right now, I can write a Ruby script. It will run on a Java platform, a .NET platform, and a standalone environment. To anyone who has to work in a heterogenous environment that's a big reason not to use Groovy right off the bat. Yes, it's easier to integrate with the JVM, because it really is Java. Again, I'm looking for something that I can run within the JVM that isn't necessarily Java.

3. Lastly, activity - look at the recent activity of the Groovy Wiki. Again, we can't continue to just give people credit for having an open source project.

"I'll attest to the fact that it is much easier for someone to break into Ruby programming versus Java programming."

Actually, as a long-time Java/C# programmer, I found Groovy to be notably easier to pick up than Ruby. I'd imagine most of the ONJava audience has a similar background. The ONLamp audience probably is on the other side of the fence on this one. To be fair, I'd still like to learn Ruby too.

"Portability"

Well, I guess for my needs, I'm okay with "only" being able to run on any OS supported with the JVM.

"I'm looking for something that I can run within the JVM that isn't necessarily Java."

Acutally I thought Groovy compiled directly to JVM bytecode with no intermediate Java.

"look at the recent activity of the Groovy Wiki"

Agreed, the documentation needs much work and I think it's been identified as a priority.

Looks like I'm coming into this one a little late...but I'll bite.

1. JRuby is secondary to NetBeans

Totally false. The principals at Sun...ALL the principals...have made it clear that our full-time responsibility is a solid JRuby 1.0 that can run the big popular Ruby apps (i.e. Rails, which necessitates Rake, IRB, RubyGems, Mongrel, and others). I've even gone as far as to say "I'd love to also help out language X" or "I'd also like to devote some cycles to working on C Ruby" and been told that JRuby should be my top priority. Time and time again, Sun folks are telling us and the general public that we're being hired to work on JRuby first. Trust me, if it weren't so, I'd tell you. I didn't leave one fulltime job that took away from JRuby to join another.

2. JRuby vs Groovy, Rails vs Grails

You guys can be pretty single-minded sometimes.

Groovy is Groovy. Ruby is Ruby. I like Ruby. Some of you like Groovy. The same can be said for Rails. I can't say (and certainly wouldn't presume to say) Groovy is a failure or the wrong language any more than you can say Ruby is the wrong language. It's about choice.

Think about it this way: In the UNIX world, there are two types of languages. C and everything else. The heavy lifting is done by C code...the kernel, the drivers, the libraries. In some cases, applications are also written in C...particularly where requirements demand a staticly-typed bare-metal language. In the other cases, folks use the other languages. Perl. Python. Tcl. Ruby. sh variants. Scads more. It's not unreasonable to say that UNIX variants simply would not function without those "other languages" tying it all together.

Now look at Java. The Java platform provides a kernel, drivers, and libraries, all written in Java (or in some combination of Java and C/C++). For years, everyone (including Sun) has pushed that everything should be written in Java, and that only Java deserved to be supported on the JVM. So the story ended there, and for millions of Java developers, dynlangs remained interesting toys not to be used for real work.

I dare you to tell any UNIX admin or developer they can only ever use C for anything from now on. You better be wearing body armour.

When you look at the facts, the emphasis on Java alone has raised a half-generation of developers trying to build UNIX systems with only C...trying to build a house with a hammer. The very notion is absurd. It's just as absurd to say there should be one true dynlang on the JVM, be it Groovy or Ruby or Python or anything else. We are craftsmen, if not artists, and no craftsman will claim that a single tool can do everything.

So I ask you these few questions:

1. Should there not be a Ruby implementation for Java?
2. Should we not try to make Rails run and integrate with as many Java frameworks as possible? (We already have extremely compelling tie-ins with JDBC and JMX...and the possibilities are endless)
3. After fighting for alternative languages to curry favor with the development community, does it make sense to claim our language is the one true choice? And the same question with alternative web frameworks?

Come now, friends. We're smarter than that.

I do not regard using RoR active record as progress when you can have JPA i do not think RoR MVC is progress when you can have java server faces or apaches Tapestry. I think there are some things java can learn from RoR but let not throw the strong points of java away. So I think implementing RoR on the jvm is useless.

@Charles
Finally! A member of the Ruby community that speaks some sense! You have exactly the right attitude Charles. Yes we should have Ruby on the JVM! Yes we should try to get Rails to run on the JVM! Does this exclude Groovy and Grails? Absolutely not, it is about choice and Ruby/Rails doesn't solve every problem

@Tim
Grails is clearly behind in feature set when compared to Rails, but then I would not call it a derivative. It has the essence of Rails, but uses technologies that Java developers are more comfortable with like Spring, Hibernate, SiteMesh and Quartz (and we will likely use Lucerne for search). This is the whole goal, we're not trying to re-invent the wheel.

The developer list my be fairly quite, but most conversation happens on IRC/chat. The user list is very active

In terms of Groovy, it is not just about having a Rubisque scripting language on the JVM. Groovy has the same runtime model and uses the same APIs with extensions added with the GDK. A Java developer does not have to a learn an entirely new collections library because its all there.

To dismiss Groovy & Grails as toy projects that shouldn't exist is just naive and Ruby people need to get out of the seige mentality of thinking everyone else is the enemy. Really, there is enough space for everyone, I promise!

And btw to says that the Ruby/Rails community is smaller than the Java community is also an understatement. As I said all things are relative ;-)

Graeme

And btw, I'm happy you've chosen not to use Groovy in favour of Ruby, its good to have diversity. The thing is don't go around calling projects meaningless and failures if you've made these choices.

One thing is having an opinion, another thing is being openly dismissive and resentful of other projects that have an active user base. My advice is to try be a little more diplomatic in future, it will present a better impression.

Graeme

@G

"One thing is having an opinion, another thing is being openly dismissive and resentful of other projects that have an active user base. My advice is to try be a little more diplomatic in future, it will present a better impression."

Resentful? Not really, just opinionated. Hmmm. Guess what, diplomacy is the problem in open source. If anything the open source world needs a little less diplomacy, and more firm opinion. Again, i'll say it for the record, I use Groovy for a few things, when it works it works, but it just doesn't have simplicity of design I see in Ruby. Sorry you didn't like my opinion, I'm far from alone on this one.

And Grails, aside from the headline grabbing title, it just hasn't gained steam, and it doesn't look like it's experience growth despite the book and the training. Again, apologies if you don't like the opinion, again, I guess I missed the rule that said that people weren't allowed to have opinions. Oh, i forgot, it's open source, we're all supposed to just honor each other and go to conferences.

Again, I'll stand by it. Groovy is a niche language, and it will continue to be just that. Ruby is going to have a much larger reach. Regardless of what Charles says, I've got no interest in getting more people to like what I'm saying. When Charles is finished getting JRuby polished, using Groovy will be a choice to use a language with far less reach and a relatively dormant development base.

@Charles,

Congratulations, I wish you luck at Sun. Godspeed. You are our only hope.

"1. JRuby is secondary to NetBeans

Totally false. The principals at Sun...ALL the principals...have made it clear that our full-time responsibility is a solid JRuby 1.0 that can run the big popular Ruby apps (i.e. Rails, which necessitates Rake, IRB, RubyGems, Mongrel, and others)."

Perfect. Thanks for the clarifications. Tim B's blog post aside, this response has me dancing for joy.

"It's just as absurd to say there should be one true dynlang on the JVM, be it Groovy or Ruby or Python or anything else. We are craftsmen, if not artists, and no craftsman will claim that a single tool can do everything."

But, many craftsmen will tell you that certain paints or certains tools are a bad idea, and they will go on and on about how they'd prefer to work with one set of tools over another. See the initial response from "Tom", he essentially says that there is no reaons to do this because of Grails.

Again, you now work for the UN of Java, and everything you say will be placed under a microscope, I understand your reluctance to make waves, but I'm not under that restriction. Again, good luck, my, IMO, the dynlang solution is Ruby or Python, Groovy is too inbetween worlds to count and as such it actually tends to get in the way more than it helps.

If you ask me, JRuby is between worlds (Ruby and Java), effectively creating a bridge between the two which are totally agnostic of one another. I'm afraid JRuby will continually be trying to deal with the inherent incompatibilities between those two worlds.

Groovy, on the other hand, is firmly in the Java world. It is meant to exist only in the JVM environment. It takes full advantage of the huge platform and codebase upon which it's been established. For the thousands upon thousands of companies who (almost exclusively) rely on the Java platform, this should be more than sufficient.

It's about time. They should have hired Jim Hugunin back in the day. Oh well I like Ruby better anyway.

You should read that as "something with pictures they can sell support for."

My take: JRuby will be good for enabling end user scripting of my Java application. With little effort, we will be able to claim that our Java applications are scriptable by Javascript, VB, and Ruby.

But as an Java application developer, I will be using Groovy, because of its strong synergy with Java platform. Yes, this means Groovy is a niche language -- a very important niche for Java programmers.

I think it is important to keep the two perspectives (end-user scripting versus application development) in mind when discussing Groovy versus JRuby.

I put JRuby in the same category as Rhino -- it allows me to offer end users the ability to script my Java applications in a popular scripting language. The end user doesn't even know that the underlying platform is Java.

Groovy, on the other hand, improves my productivity when programming the Java platform. It will help the Java platform move beyond its current strength in the enterprise market and enter markets where more agile development is valued. I believe this is crucial for Java's long term success.