Discussions

News: To Groovy or to JRuby? That is the Question

  1. Scripting for the JVM is a hot topic. Shay Banon asks, "What should a developer learn? Should it be Groovy or JRuby?" and provides an interesting analysis of the pros of both choices. Shay goes on to clarify that proficiency in the language is not enough.
    Learning the syntax is usually the simple task, but it is important to understand that it does not end there. In order to really know how to use the language, we need to know all the different popular frameworks that comes with it, idioms on how to use it, and so on. If we take the Java world as an example, it is not enough to learn Java as a language, developers need to be familiar with Java design patterns, core Java concepts and design patterns, JEE, Spring and many others.
    Self-contained scripting languages tend to be useful for tools and one-liners. Scripting languages for application development, on the other hand, can succeed only if they come with a rich library like Ruby on Rails, or if they can leverage the existing infrastructure, like Groovy does. It's not clear whether something like JRuby, straddling both worlds, is a good or bad thing. There are also efforts like Microsoft's opening of the Common Language Runtime to better accommodate third party languages, instantly allowing developers to mix and match languages and libraries within that environment. For the Java universe, are Groovy and JRuby the best choices? Are there others? What do you think?

    Threaded Messages (35)

  2. The answer is Jython[ Go to top ]

    it just works..
  3. Re: The answer is Jython[ Go to top ]

    it just works..
    Not very helpful. If you are going to advertise ${scripting.languages.personalFavorite} then would you care to point out something beyond the fact that you've used it. What makes it the best?
  4. Re: The answer is Jython[ Go to top ]

    May be I should say "My anwser is Jython" instead. Today I was really busy at work but even so I had some minutes to read an interview: http://www.infoq.com/news/2007/05/fdd-jeff-de-luca-interview It's regarding a totally diferent (but also hot) topic: Agile methodologies At some point, the interviewed person (Jeff de Luca) says: "...You read that book, and one or two of the methods are going to resonate with you and your team. And whichever methods those are, they are the ones you should explore. In other words I'm saying that the Agile methods are more suited to types of people and organisational cultures than types of project." The sames applies to a JVM script language: you need to select and experiment based on your own expectations and experiences (try it!), there is no such thing like the best one, fortunately.
  5. Groovy does it for me[ Go to top ]

    I have a ruby book that has been sitting on my shelf for at least a year and I just haven't been motivated into learning the language beyond it's basic syntax. In contrast, I've been playing with Groovy as a language for my integration testing and I've been impressed with the way Groovy lets me leverage my Java knowledge while learning the very convenient syntactic sugar of Groovy. Maven integration is still a little raw for me but I know it's being worked on and currently maven will let you compile and run Groovy test classes which effectively allows Maven to be my "Groovy container" as I learn Groovy in a test-driven fashion . So, just based on the "lazy index", Groovy wins for me.
  6. Agreed[ Go to top ]

    Agreed. I prefer Groovy because being a Java developer, I can leverage all my existing knowledge of the platform and third party tools, while incrementally learning to utilize the powerful features of a dynamic language. And Groovy makes this very easy by following many of Java's idioms and syntax where appropriate. It's either that, or learn a new language and a new API/platform.
  7. Re: Groovy does it for me[ Go to top ]

    I have a ruby book that has been sitting on my shelf for at least a year and I just haven't been motivated into learning the language beyond it's basic syntax.
    Same experience here. The pickaxe book is a great book but if you don't have a reason to use Ruby daily it is hard to get motivated to really learn it. Groovy is a tool I'm using daily now to solve some Java pains, which keeps me motivated and learning more.
  8. Re: The answer is Jython[ Go to top ]

    it just works..
    ...albeit very slowly. And it only supports Python 2.1 while CPython is up to 2.5.1. Why is the answer Jython?
  9. Re: The answer is Jython[ Go to top ]

    ...albeit very slowly.
    Jython used to be the faster JVM script language. May be today Groovy outperformed Jython (the last time I tried was years ago) but JRuby definitely not did it, at least yet. Beside this, if performance is more important than the inherent (and amazing) productivity of scripting, I would keep with Java. Jython never had a JSR but some smart Weblogic and Websphere admins are using Jython to make administrative tasks scripts for years. http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting.html
  10. By:
    ...but some smart Weblogic and Websphere admins are using Jython to make administrative tasks scripts for years.
    I meant:
    ...but some smart Weblogic and Websphere admins have been using Jython to make administrative tasks scripts for years.
  11. It depends[ Go to top ]

    I think it depends on where you have been already and where you want to go. This space here tends to be dominated by Java people, so assuming that is what your background is in, Groovy would appear to be the better choice. But, it also depends on where you want your career to go in terms of skillset. Groovy will be easier for a seasoned Java developer to pick up for reasons stated quite well by other comments above, but if you want to get involved in quick hit webapp consulting for small and medium businesses where Ruby seems to have found a nice niche, then it is probably worth it to give JRuby a shot. In the enterprise environment I work in, Ruby is essentially a 4 letter word and I'm pretty happy where I am so I'd choose Groovy for me. For others, though, there are a lot of valid reasons you might choose differently. ---Pete nerdguru.net
  12. It is worthwhile to spend some time with both (and maybe others) but for those new to scripting but consider themselves Java/JDK experts Groovy is probably the first best choice: 1) Groovy is a SUN JSR standard (for whatever that is worth). What I think that will mean is that the language and existing platform itself is stable so you won't have to keep rewriting your code as new releases come out. 2) Support for Groovy is being built into IDEs. I'm not saying it doesn't' exist for other languages, just that it is available and improving for Groovy. 3) You don't have to relearn an entire framework again. Your underlying types are all pure JDK. JRuby supports using native Java types but also has to duplicate the Ruby framework for example. 3a) The Groovy API doesn't introduce that many new types, just extends the types with scripty goodness. Working with Files, reader/writers, streams, XML, strings, regular expressions all are extensions of the underlying JDK classes. 4) Groovy was written to work with the JVM and the Java language so it has less of a feeling of trying to fit a square peg into a round hole. 5) Groovy's builders are really nice to work with. (Don't know ruby enough to know the equivalent but I'm sure there is one) 6) Java frameworks like Spring are writing specific Groovy hooks so there is some indication that 3rd party frameworks will prefer Groovy integration. 7) Industry support is important and means Groovy could be the first JVM scripting language allowed in the door at more conservative development shops. Actually, I think Rhino (JavaScript) is being packaged with JDK 6 I may be wrong on this one. 8) Built in support for JUnit, JDBC, etc. 9) Good documentation, examples, books. "Goovy in Action" is a well done book. I learned a lot. Others? I could see learning JRuby if you were planning on also using pure ruby. Sounds like they are close to having RoR work with JRuby too. Grails? Still early in development (thing they are just releasing 0.5) but it is fun to play with. Actually, I understand RoR and the Ruby language a lot better now that I've been playing with Groovy/Grails. Even though Grails development is a few years behind RoR, I think they'll catch up (and surpass?) pretty quickly. Why? 1) They had RoR to steal from so they didn't have to spend time coming up with and improving the concept 2) It sits on top of Spring and Hibernate they didn't have to reinvent ActiveRecord or some other ORM. 2a) It can directly use any existing Java library, framework, or legacy code. If you don't like what comes with Grails, you can use anything in the Java universe instead. 3) They also didn't have to invent a way to make it stable or performant. Groovy complies down to the same bytecode as Java. Grails uses the same J2EE web standards and can produce a standard WAR file. So unlike RoR you can use time and industry tested containers like Tomcat. It seems with RoR they are still working towards stability, salability, standards, and performance. Mongrel is only a couple of years old right? Please note I have a lot of respect for Ruby and RoR so I'm not trying to start a flame war. Just opinions and predictions which I'd be happy to have rebutted by the more informed. I stand by my opinion that a good Java developer should pick up Groovy first because it is easy to get started and be proficient.
  13. 1) Groovy is a SUN JSR standard (for whatever that is worth).
    To be clear, the Groovy Language JSR (JSR 241) was *not* submitted to the Java Community Process (JCP) by Sun, although Sun voted to accept it, and is pleased with its progress. It is a very useful tool for the existing Java developer community, although it has fairly limited acceptance *outside* that community.
  14. Groovey for Java programmers. JRuby for Ruby programmers who need to interact with Java Applications or use Java class libraries. C based Ruby and all the other C based scripting languages like Perl, Tcl, and Python already have write once run anywhere capability as there are distributions available for virtually all hardware and OS platforms. There is no compelling requirement for a JVM based runtime environment as most of the scripting languages already provide interoperability with Java using the appropriate language extension e.g Perl - "inLine Java", Tcl - "TclBlend". Ditto for the Microsoft CLR.
  15. C based Ruby and all the other C based scripting languages like Perl, Tcl, and Python already have write once run anywhere capability as there are distributions available for virtually all hardware and OS platforms. There is no compelling requirement for a JVM based runtime environment as most of the scripting languages already provide interoperability with Java using the appropriate language extension e.g Perl - "inLine Java", Tcl - "TclBlend".

    Ditto for the Microsoft CLR.
    there are other benefits in having scripting languages in the JVM. When JRuby get a complete compiler for the JVM, it will probably run much faster than its C based implementation, which AFAIK is interpreted. Scripting languages can benefit from advanced garbage collector, JIT compiler and more straightforward interoperability too, so there are actually a few compelling reasons for implementing them in the JVM.
  16. Perl is the most popular scripting language in the world but it has not been ported to the JVM. I rest my case. :).
  17. Perl is the most popular scripting language in the world but it has not been ported to the JVM. I rest my case. :).
    Actual it was. See http://ebb.org/perljvm/ But it looks like there was no real interest in it.
  18. 1) Groovy is a SUN JSR standard (for whatever that is worth).


    To be clear, the Groovy Language JSR (JSR 241) was *not* submitted to the Java Community Process (JCP) by Sun, although Sun voted to accept it, and is pleased with its progress. It is a very useful tool for the existing Java developer community, although it has fairly limited acceptance *outside* that community.
    I got that part wrong, thanks for cleaing it up.
  19. 1) Groovy is a SUN JSR standard (for whatever that is worth).


    To be clear, the Groovy Language JSR (JSR 241) was *not* submitted to the Java Community Process (JCP) by Sun, although Sun voted to accept it, and is pleased with its progress. It is a very useful tool for the existing Java developer community, although it has fairly limited acceptance *outside* that community.


    I got that part wrong, thanks for cleaing it up.
    More important is that Groovy 1.0 is not JSR Groovy. JSR 241 is in an early stage (http://www.jcp.org/en/jsr/detail?id=241) Nebojsa
  20. "It's not clear whether something like JRuby, straddling both worlds, is a good or bad thing. " What's important about JRuby, and other projects like it, is that it's a step towards Java as a language platform. It looks to me like Java will take the path of it's predecessor's, and will be used to make JVM's and compilers for other languages. Regarding the choice, to me it's more about a philosophy of development. Those that maintain Java have a much different goal than those of Ruby. Java tries to make the interpretor happy, and Ruby tries to make the programmer happy. Both are good for their own purposes. All in all the lesson is that you don't have to make a choice. The curve on these new frameworks is becoming smaller, and it's more likely that you can pick them up as needed. Especially when everything can run in a servlet container.
  21. none of them stand a chance[ Go to top ]

    if you want to do any serious development more than 2000 pages, more than 1000 objects in domain model, a lot of backends to connect to - then Ruby or Groovy both fail to deliver. Theyare just not made for it. This is based on my personal experience of trying our best to use them both in a special initiative in a mid size B2C and partly B2B company which wanted to have some agile development model and faster time to market with least learning curve for new comers. It turned out best bet is pure java with web services etc is the best. ( Spring is the way to go. ) Ofcourse you will have your own examples defying me.. well you may be true in your own little world. We and all our clients rejected it out the door after wasting 6 months of serious attempt. No more replies from me on this thread.....you dont need to defend your ideas and i dont want to waste my time either. EOM.
  22. dink.
  23. if you want to do any serious development more than 2000 pages, more than 1000 objects in domain model, a lot of backends to connect to - then Ruby or Groovy both fail to deliver. Theyare just not made for it.
    I think this misses the point of groovy. Groovy is meant to be used with java, not instead of it. It's not a java vs groovy choice. It's java vs java + groovy. I have started using groovy as an interactive environment to "play with" objects live. This stops me from writing example classes or unit tests when all I really want to know is how a class actually works. You can write pieces of your app in groovy, then refactor on a class by class basis to java if and when tou need the performance. For example, if you want to prototype a SOAP interface, do it in groovy first because it will take 5 minutes. If you use interfaces (which is a big advantage of groovy over ruby and jruby) you can implement an interface with a groovy prototype and later add a java one. Apply spring's dependency injection things are very easy. Some things, like tests or templating or ant may end up being in groovy permanently. Swing glue code seems like a big candidate to stay groovy, because of groovy's swing builder.
  24. Good points but I didn't want to give the troll his donut. Look at shawn's post history at TSS and see if you don't stand by my four-letter assessment of his character. http://www.theserverside.com/user/userthreads.tss?user_id=154780 Only a fool would try to create an entire enterprise application using a pre-release scripting language. Groovy 1.0 was only released in January so I'm thinking that there was a good reason shawn's 2000 page web app failure made him into a bitter troll.
  25. Me thinks you are missing the point of what Rails or Groovy are for.
  26. to fully hotswap java offcourse, what else?
  27. There's also F3[ Go to top ]

    Sun has something new, to compete in the Flash space, called F3. Take a look at this blog entry: http://blogs.sun.com/chrisoliver/category/F3 I've worked with it a little, and it's not bad. It makes GUI programming a lot easier than it is with Swing.
  28. Why choose?[ Go to top ]

    The article presents JRuby and Groovy as an either-or choice. Why? If you're a smart developer who likes to learn new skills, why not learn both? JRuby vs. Groovy exclusivity is like saying "should I learn to use a screwdriver or a hammer?" or "should I learn to drive a manual transmission or an automatic?" JRuby and Groovy are both tools that each have their own pros and cons, learning new skills/tools broadens your perspective and makes you a better developer.
  29. Have we forgotten[ Go to top ]

    For many years the distinction between scripting languages and well structured languages such as Java, and the relative merits of the 2 were well understood i.e. Scripting = quick turnaround but leads to difficult to maintain code when a certain threshold of complexity is exceeded. With the arrival of Ruby et al it seems to me that this has been forgotten. Or is it that people no longer subscribe to this view point. From the little I have seen of Ruby, JRuby, Groovy, etc. this assertion still holds true.
  30. Re: Have we forgotten[ Go to top ]

    For many years the distinction between scripting languages and well structured languages such as Java, and the relative merits of the 2 were well understood i.e. Scripting = quick turnaround but leads to difficult to maintain code when a certain threshold of complexity is exceeded. With the arrival of Ruby et al it seems to me that this has been forgotten. Or is it that people no longer subscribe to this view point. From the little I have seen of Ruby, JRuby, Groovy, etc. this assertion still holds true.
    I think that there is truth to what you are saying but I think many are leaning toward the idea that, sure, build your frameworks (Hibernate, Spring, etc) in solid Java but use a higher level language to glue the frameworks together, create your UI, test your code, etc. I think frameworks like RoR are trying to push the "certain threshold" up higher by reducing the amount of configuration and explicit wiring needed to get a decent sized application working. Ruby purists may balk at the structured-language argument altogether but I'm not in that boat yet. Groovy, JRuby, et al are powerful tools for the conscientious designer. Used tastefully I'd guess your application would be more-maintainable. Notice I purposely didn't say "scripting language" because of negative connotations.
  31. Our product is made possible via Jython. Lemme explain: we make a product called Vamosa Content Migrator, which automates the migration of content into content management systems (CMS). Now content migration is often dirty and nasty, because content is often dirty and nasty. Its typically made by humans for humans, not machines. So our product allows users to build custom tasks that performs operations on content as it travels through into the target CMS, e.g.: "remove font tags", "make accessibility-compliant", "add metadata" etc etc. All these tasks are written in Jython re-using a Java-based object model that we provide out of the box. So we as a company focus on providing the best general purpose content manipulation toolbox (via the Java object model) and our customers and partners build libraries of little tasks that suit their purposes. We also provide our own libraries of Jython tasks, such as our connectors into content management repositories. In our latest release we've taken this a step further by using "introspection" which looks at a Jython script, gets an understanding of the IN/OUT parameters (kinda like stored procedures) and uses that "parameter info" to drive the GUI. The end user can then work at a higher-level of abstraction, diagramatically wiring tasks together, providing defaults values for IN-params, etc. So the Jython-introspection allows us to separate the task-writer from the task user. All cool stuff. Now I'm sure some of what I've described is possible in other object-based scripting languages, especially Groovy (although I have little experience with it). Jython is so simple and easy to use. Everyone that uses our software and had no contact with Python previously raves about it. This took a turn for the worse recently though, when our COO, a guy in mid-40s, got his hands dirty and started writing tasks. I can't imagine him getting his head around Ruby-syntax: its too "esoterical". Now with regards to Jython lagging behind CPython (2.2 vs 2.5): that's never been a problem with us. There's obviously lack of newer library-functionality, but that is easily made up by finding an equivalent Java-library and dropping it into the "lib/" folder. To finish off, I can whole-heartedly recommend Jython as a scripting & gluecode language. If you want to take a look, check out this page (apologies for the plug). Regards, Ijonas Kisselbach CTO Vamosa
  32. Hey, thanks for the case study. I wish we had more posts that calmly explained successes or failures- where a higher level language added value and where it didn't work out and why. As a guy fast approaching 40 myself I'm not sure I'm down with your ageist comment about your COO :-) If he is tech-deficient it isn't because of his age. The most savvy tech guys I know are in the 35-50 range.
  33. Sorry, didn't mean to be ageist. I should've said he (my COO) comes from the Cobol-era/arena. That's where he learned his trade, and probably did most of his programming. He said Python reminded him of BASIC, but without the line numbers. And he's right, the language excels at readibility and therefore really suits are needs. I can understand some people not liking Jython/Python's dependence on whitespace/indentation but I personally find it one of its greatest features. Each to their own I guess. Cheers, Ijonas Kisselbach CTO Vamosa
  34. Hey, thanks for the case study. I wish we had more posts that calmly explained successes or failures- where a higher level language added value and where it didn't work out and why.

    As a guy fast approaching 40 myself I'm not sure I'm down with your ageist comment about your COO :-) If he is tech-deficient it isn't because of his age. The most savvy tech guys I know are in the 35-50 range.
    I quite agree. The post was pretty good - except for the COO comment. I am looking back at 40 and having a few years of experience :) , I can say that age has little to do with it.
  35. i will obviously select "JRuby" instead of groovy. i am really big fan of Ruby and RoR from the very early stage. you can say i am kinda fan of ruby ruby syntax. wishing to see spring is providing whole xml configuration over ruby script. because it will enable lot of customization over the spring container. for example: if @platform == 'development' bean = Bean.new :key => "connection", :implementation => "ClassName" @beanContainer.register bean else if @platform == 'production' bean = Bean.new :key => "connection", :implementation => "ClassName2" @beanContainer.register bean # .... end best wishes,
  36. Ruby, Groovy and Grails[ Go to top ]

    I like any language that let's me be more productive. That being said I think Ruby on Rails is the best language/platform at the moment. As other have said, Groovy is a natural choice for your day job since it leverages existing knowledge of Java. Although Grails is still pretty young, it will be interesting to see if it eventually competes with Ruby on Rails. The only bad thing I see with Grails is that it still requires a servlet container to run. Most web hosts still have a limited support for Java while there is a lot of momentum for supporting Ruby/RoR. For those interested in Ruby/RoR, go to http://www.rubymatters.com.