Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Your Thoughts on the Groovy Scripting Language? 128

lelitsch asks: "Does anyone have first hand experience with Groovy? I am just coming off implementing a Plone-based intranet CMS and got hooked on scripting languages and Python all over again. Since most of my projects in the near future are going to be in Java or have large Java components, I was wondering if it's time to trade Jython--which seems to be falling further behind the Python release cycle--for something else. Groovy sounds like a fun thing to look at, but it seems a bit new and thin. Also, what are other languages (JRuby and Rhino, for example) you have used to script in Java?"
This discussion has been archived. No new comments can be posted.

Your Thoughts on the Groovy Scripting Language?

Comments Filter:
  • Ruby (Score:2, Informative)

    by Anml4ixoye ( 264762 ) on Tuesday April 18, 2006 @10:11PM (#15154442) Homepage
    I also have been enjoying scripting languages, mostly Ruby. JRuby is still in active development, contrary to belief, and they have versions of IRB running with it.

    I'm giving a presentation on using Ruby for scriptable .NET apps at an upcoming Code Camp in St. Louis.

    I haven't played much with Groovy, but I like the idea of Ruby in that I can write scripts that will run standalone, in .NET, or in Java (not that Ruby is the only one that can do that)
  • Bean Shell Script (Score:5, Informative)

    by Elias Ross ( 1260 ) on Tuesday April 18, 2006 @10:14PM (#15154457) Homepage
    From what I've seen, Groovy's a half-baked programming language and unfinished product. See this [] criticism for a start.

    If you want to do embedded scripting in Java, I suggest Bean Shell [] instead. As a library, Bean Shell is about 280K, Groovy is about 1.7M. And Bean Shell has been around for a lot longer.

    I'd like to see Sun add closures and better support for lists/maps in Java itself (e.g. a map function). I'm hoping that pressure from Ruby will make the language grow. C# already made them change their mind about Generics.
  • Nothing beats Lua (Score:5, Informative)

    by Cthefuture ( 665326 ) on Tuesday April 18, 2006 @10:32PM (#15154524)
    for lightness and performance. At least as far as scripting languages go. I can't say I'm a fan of Java but if you insist:

    There is Java/Lua integration in the form of JLua [] and LuaJava []. Possibly other tools as well.
  • Re:Nothing beats Lua (Score:4, Informative)

    by Johnso ( 520335 ) on Tuesday April 18, 2006 @10:58PM (#15154614)
    Seconded. Lua is the nicest scripting language I've worked with. It embeds beautifully in both Java and .Net. [] is your friend.

  • by Decaff ( 42676 ) on Tuesday April 18, 2006 @11:39PM (#15154759)
    Given than Jython and JRuby exist, and Groovy doesn't offer much that they don't, what is the point other than to be deliberately obscure?

    Groovy does offer things they don't, primarily the ability to compile to class files so that Groovy classes can be used from Java classes and vice versa. This also allows Groovy to run at high speed (as the byte code in the class files is optimised at run time).

    However, JRuby plans to allows this in the near future as well.
  • by swdunlop ( 103066 ) <> on Wednesday April 19, 2006 @12:00AM (#15154822) Homepage
    There is JScheme [], and Kawa. []

  • by RovingSlug ( 26517 ) on Wednesday April 19, 2006 @01:00AM (#15154991)
    Fyi, I have also used Jpype [] with success, which allows bidirectional operation between Java and CPython.
  • Hecl (Score:3, Informative)

    by DavidNWelton ( 142216 ) on Wednesday April 19, 2006 @02:09AM (#15155166) Homepage
    Hecl: []

    it is perhaps less general-purpose than the poster might want, but I have different design considerations in mind:

    Small, flexible, very dynamic, and concise - in other words, I want it to be a complement to Java, rather than simply a scriptable Java, ala Beanshell. This means that perhaps you wouldn't want to write the entire app in Hecl, but on the other hand, as a language to write quick extensions with, perhaps it's a bit faster/easier to work with.

    The most interesting feature at this point is that Hecl is small enough to run on Java-enabled cell phones, even pretty basic ones like my Nokia 3100, which only accepts Java stuff - no symbian. This means that you can code apps with no recompiling, and also make them very dynamic (you could make an app that downloads code, stores it and runs it as needs be).

    Also, for the folks who like this stuff, Hecl is still young, so there's lots of room to fiddle with the language itself, and learn about how a scripting language is built [].

    Astute observers will note that Hecl is similar to Jacl, but like the poster complaining about Jython getting a little bit out of date... it always seemed like a bit of a losing proposition to me to do a copy of a language in Java, because you miss out, if nothing else, on a *lot* of libraries, and the JRuby/Python/Tcl implementations have always seemed to be playing catch-up.
  • by SuperKendall ( 25149 ) * on Wednesday April 19, 2006 @03:12AM (#15155309)
    Come on, there was a beta version of Generics floating around (that worked in 1.4) before C# was even out. The guys adding Generics wanted to add it much sooner (even in 1.3 I think) but there was too much contention in the community about how best to add it.

    Java was a little slower actually getting it in, but that's because they had a lot of legacy code to consider and how to make generics that would be useful even with older libraries. In no way was Java actually pressured to include Generics just becasue C# had it, they faced a lot more pressure from a world of developers wanting something like generics from 1.0 on.
  • by Anonymous Coward on Wednesday April 19, 2006 @03:17AM (#15155327)
    There is a really nice Scheme interpreter on the JVM called SISC: []

    IMNSHO Scheme is so much nicer than Python et al that there's not even a decision to be made here as far as dynamic languages on the JVM.

    There's also Scala, which is another statically typed language on the JVM. It is SORT of like Java, and can use Java classes natively, but is about 20 times more pleasant to use than Java (if you're into higher-order functions and pattern matching and that kind of thing... but then, everyone should be into that stuff). Anyway, Scala isn't a scripting language, but depending on what you're planning on doing, using it may persuade you that you didn't actually need a scripting language, you just needed a language that wasn't painful to use like Java is.

    Scala: []
  • Re:Bean Shell Script (Score:5, Informative)

    by Will Sargent ( 2751 ) on Wednesday April 19, 2006 @03:29AM (#15155359) Homepage
    Also see Mike Spille's [] criticism.
  • by Anonymous Coward on Wednesday April 19, 2006 @04:57AM (#15155573)
    Or, how about trying SISC []?
  • fact clarification (Score:1, Informative)

    by Anonymous Coward on Wednesday April 19, 2006 @08:55AM (#15156177)
    Intergalactic Digital Research (not DIR) was the original name of Digital Research (who sold CP/M and DR DOS) not Digital Equipment Corporation (selling the scrummy VAX minicomputers)
  • by Anonymous Coward on Wednesday April 19, 2006 @09:48AM (#15156490)

    you wrote:
    > Perl: map { $_ * 2 } @arr;
    > Java: for( Integer key : arr ) { key *=2; }

    This is clearly not what 'map' is intended for.
    map works entirely in 'block context', it
    takes a list (array) as a whole, does something
    an returns another list (array). You wouldn't
    modify the original array in a map block.

    This is what you might 'map' use for:
    @words = ('here', 'we', 'have', 'some', 'words');
    @indices = (1, 2, 3, 4, 5);

    print join '_', map { $words[ $_-1 ] } reverse @indices;


  • by jasondlee ( 70657 ) on Wednesday April 19, 2006 @09:48AM (#15156494)
    The rule we use around the shop is what my boss calls the Front Porch Test, which really comes from the pet world. It goes something like this: When naming a pet, imagine yourself standing on your front porch calling loudly for your pet (presumably a dog, as cats come around when they want ;). If you would feel stupid if your neighbor were to hear you yelling the proposed name, then don't pick that name. We apply the same logic to application/system names. Works pretty well for us.

    There are exceptions, however. More accurately, we have our inside names and the names we tell our customers. For example, we have one web app that allows our users to search for orders in the system, which they call Order Finder, a nice, generic, informative name. The URI for the app is /dwmo, which reflects our internal name, "Dude, Where's My Order." :)
  • by Anonymous Coward on Wednesday April 19, 2006 @09:59AM (#15156611)
    In Perl:
    map { $_ * 2 } @arr;
    In Java:
    for( Integer key : arr ) { key *=2; }
    That Java code doesn't do anything. The variable named 'key' starts by holding a reference to an Integer object; then you (implicitly) call Integer.intValue() and multiply the result by 2; and then call Integer.valueOf(that) to get a reference to a new Integer object; and that object reference is stored back in the variable 'key', replacing 'key''s original object reference.

    Variables in Java do store references (pointers) to objects - but when you use the "=" operator (including "*=", "+=", "++", etc), it assigns a new object reference to that variable, and does not affect the object which was previously referred to. It's like saying "int i; int* pi = &i; ...; pi = &((*pi) * 2)" in C (except more valid), and the value of i is never changed.

    To modify it in-place, you'd have to do something like

    ListIterator<Integer>; it = arr.listIterator();
    for (Integer i =; it.hasNext(); i = { it.set(i*2); }
    (though that only works if it's a List of Integers, and you have to write completely different code if it's an array). If you don't want to modify the original, that'd be
    List<Integer> arr2 = new LinkedList<Integer>();
    for (Integer i : arr) { arr2.add(i*2); }
    It works, but it's just a little bit inelegant.
  • by bwt ( 68845 ) on Wednesday April 19, 2006 @10:46AM (#15157035) Homepage
    Groovy offers significant advantages over jython and jruby because it was designed specifically to run in the JVM. In particular: a) groovy's class library is the java class library -- you do not subject development teams to two competing sets of class libraries, b) groovy compiles to bytecode which means its interoperability with java is seamless c) groovy can and does actually add syntax and functionality to existing java classes via the GDK.

    The problem with groovy is that it is young. It is just starting into the release candidate phase. Some people have written articles bashing groovy for missing expected features like good parsing error feedback. These articles are unfair since they are evaluating a product that is unfinished. I do not recommend groovy for any production purpose yet, it's simply not ready.
  • Rhino / ecmascript. (Score:2, Informative)

    by gedhrel ( 241953 ) on Wednesday April 19, 2006 @11:22AM (#15157417)
    I've used the rhino implementation of javascript as the basis for a scripting engine in a number of projects now. Javascript is lightweight, supports many useful idioms, and with rhino, integrates well with existing apps. Exposing your APIs to a scripting layer is pretty simple.

    What particularly attracted me to rhino (apart from being a bit of a js nut) was the security model. That is to say, it has one, and it's pretty well worked out. It's typically nontrivial to add sandboxed scripting support to an application that integrates with the application's model of user permissions*: if you look around, you'll find lots of examples of various scripting languages being plumbed into applications, but typically the scripting layer is available to "admins only" due to these kinds of security concerns.

    * even in java, which already has a semi-decent security model**

    ** It's a lot of work getting security providers to stack properly. Layering application-domain runtime security over an application running inside a container with its own security provider is barely doable.

10.0 times 0.1 is hardly ever 1.0.