Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

Groovy in Action 154

Posted by samzenpus from the look-at-all-the-colors dept.
Simon P. Chappell writes "I missed the partying in the 70's and so was not exposed to the full groovy experience that was available. You could say that I was a late developer (pun intended). Thankfully, I am now able to make up for lost time by learning the Groovy scripting language. For those of you not familiar with Groovy, it is a dynamic language designed to run on a Java Virtual Machine and be easy for Java programmers to work with; it looks very similar to Java and will freely inter-operate with Java objects and libraries. I've been tinkering with Groovy on and off for about two years now; learning Groovy in the old days, prior to this year, was a challenge with all of the design changes that were taking place. Groovy in Action (GinA) is the book that I'd wished was available back then. Dierk König, a committer for the Groovy project, has written this definitive guide to Groovy and after what has seemed an eternity to those of us on the Groovy mailing list, it is finally available." Read below for the rest of Simon's review.
Groovy in Action
author Dierk König, Andrew Glover, Paul King, Guillaume Laforge, Jon Skeet
pages 659
publisher Manning
rating 9
reviewer Simon P. Chappell
ISBN 1932394842
summary A practical how-to book for Groovy


The obvious candidate for this book is the programmer that wants to learn Groovy. What is less obvious, is just who those people are, because programmers who would find Groovy useful are likely to come from quite a wide selection of backgrounds. If you thought that Groovy wasn't for you, read on and consider whether you may have judged in haste.

Current, or former, Java programmers will love Groovy and they will likely make up the greatest proportion of the readership. They will especially appreciate the interoperability of Groovy with Java: your Groovy objects are Java objects, right down to the bytecode level.

As a dynamic language, Groovy attracts a good quantity of the traditional users of scripting languages. Expect to see more than a few system administrators and build managers pick up on Groovy as they realise the benefits it brings. Further sweetening the pot, for build managers, is the ability to use Groovy as a scripting language within Ant. Another group of readers may well come from the dynamic language communities. I think that Ruby and Python programmers may well find this an interesting book to help them understand this new arrival on the scene. With the steady maturing of the Grails project, that uses Groovy as it's implementation and development language, even the Ruby on Rails folks might be curious.

For a book that's setting out to teach you a programming language, the structure is fairly standard. The contents are divided between three parts that theme the Groovy Language, the Groovy Libraries and then wrap up with Everyday Groovy. I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it. This is a very welcome development in programming language books; other publishers and authors please take note!

For the purpose of full disclosure: I had been talking to Manning about writing more of a practical how-to book for Groovy, but with GinA being so good, those conversations stopped almost as soon as they got started.

The first chapter is the standard fare of what Groovy is and why you want to use it. This is important material for those who may be new to the language and it's covered very well. Some book's initial chapters can be a little dry, as if the author was in a hurry to get to the good stuff, but here, Mr. König has recognised that the language is in an early enough phase that explaining why you would want to use it is the good stuff.

I'll save you from a big list of chapter headings and just relate that part one covers the basics, including how to compile and run code and how to run it as an interpreted script. The fundamental Groovy datatypes are introduced and we learn about the joys of optional typing, for those occasions when it's not obvious that the object is a duck. Groovy has all the things you'd expect from a dynamic language: strings, regular expressions, ranges, lists, maps, closures, control structures and finally, to make it in the corporate programming world these days, it has objects.

As we skipped chapter headings for part one, I'll follow precedence and skip them for part two as well. Part one taught us the basics of the language, part two looks to help us now integrate with the Java environment and existing Java code and systems. Builders are an important part of using Groovy to it's full dynamic extent and these are covered extensively. Groovy also brings it's own library extensions for the standard Java libraries, and they are known as the GDK, even though they're technically not a development kit. Groovy works nicely with databases and is able to use any existing JDBC drivers you may have. XML, whether you love it or hate it, is a big part of the life of a corporate programmer these days. Groovy has built in smarts for working with XML and you'll learn about those in this part. There are many useful Java tools, libraries and frameworks available today and Groovy can work with almost all of them. Much good information on integrating with everything from Spring to the new scripting interface defined by JSR-223 is covered.

Part three is the Everyday Groovy part. It starts with Tips and Tricks. Things to remember, useful snippets of code, advice on calling Groovy from a command-line, and writing automation scripts. There's also a full chapter on Unit Testing with Groovy, covering testing of both Groovy and Java code. The last two chapters cover optional stuff for Groovy. Groovy on Windows looks at the use of the Scriptom tool for those who use Windows. (As a Mac user, I admit that I skipped this one.) The last chapter is an introduction to Grails, the web application framework written in Groovy and which can run in any standard J2EE environment.

There are a couple of slim appendixes at the back with installation information, language information and an API Quick Reference for the GDK.

There is much to like about GinA. Mr. König and his co-authors writing is clear and engaging and Manning's layout and typography are up to their usual excellent standards. On it's own, these are good reasons to consider this book if Groovy interests you, but when you mix in the fact that Mr. König is a committer on the Groovy project and has taken an active role in the creation of the language itself, then you have a very compelling reason to choose it.

Groovy in Action is an excellent book, written by one of the designers of the Groovy language. If you have any interest in modern scripting languages at all, I would recommend that you check out this book.

You can purchase Groovy in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Groovy in Action More

Groovy in Action

Comments Filter:
  • Groovy in Action (GinA) is the book that I'd wished was available back then.

    Is this 'gina freely available in bookstores, or do you have to show ID to see it?
    • You could have at least made reference to a user group based in Virginia: the VAGinA User Group
      • You could have at least made reference to a user group based in Virginia: the VAGinA User Group

        Doesn't that cover nearly half the population? (present company excluded, of course... this *is* slashdot, after all)

        • Re: (Score:2)

          by Anpheus ( 908711 )
          Well if you didn't fail statistics, you insensitive clod, you'd know that.

        • Re: (Score:2)

          by shmlco ( 594907 )
          Actually, if you stop to think about it from both sides of the equation, doesn't that cover nearly ALL of the population?
          • Actually, if you stop to think about it from both sides of the equation, doesn't that cover nearly ALL of the population?

            Yeah, so what we really need is a group for owners, and a group for those of us that just rent.

      • Re: (Score:2)

        by dgatwood ( 11270 )

        I was thinking "Very Awesome Groovy in Action", which would be somewhat more inclusive.

  • Finally, Slashdot links to Amazon (Score:1, Insightful)

    by Anonymous Coward
    It's nice to see that Slashdot has finally started linking to the Amazon listing [amazon.com] instead of the wildly overpriced Barnes & Noble as it inexplicably did for several years. Do, however, take a look at the "Used and new..." listings, since the third-party sellers usually offer new copies even cheaper than Amazon itself does.

  • Biased reviewer, reads like an ad for Groovy (Score:2, Informative)

    by Anonymous Coward
    The reviewer is an author of several Groovy [codehaus.org] articles and has a vested interest in seeing the book succeed. How about a little objectivity and professionalism?
  • I assume the Groovy IDE is in your choice of colors: avocado or paisley

    Startup plays "Disco Inferno"

    Comes with a draft notice for assignment to Korea (coming around again soon!)

    Has built in 300 baud serial modem to connect to a BBS

    • Re: (Score:2)

      by nuzak ( 959558 )
      > Comes with a draft notice for assignment to Korea

      Clearly a product of the US Education system. That, or you don't remember the 70's, in which case this is actually authentic.

      • Re: (Score:2)

        by Intron ( 870560 )
        Oh stupid me. Also, Afghanistan hostilities ended in 2001 and Mission Accomplished ended in Iraq in 2003. Please let our boys in Korea know that they can come home now. Somebody forgot to tell them.
        • I don't think the Korean War ever actually ended, but I do believe the draft did due to a little conflict called Vietnam. You might have heard about it. Now we just send people who want to see the far east.

        • Re: (Score:2)

          by nuzak ( 959558 )
          I may be going out on a limb here, but I think they stopped drafting people for the Korean war before 1970. Perhaps you've got it confused with M*A*S*H.

          • Re: (Score:2)

            by Intron ( 870560 )
            You aren't drafted "for a war", you are drafted into the army and they send you where they want.
    • Korea? I though that was over in '54... (Dad served) 'nam finished in 72... although you're right, we may get drafted again, well, I'm old to worry about that. BBS's, C'mon, BBS's were popular in the 80's, in the 70's people were still shoveling cards into a reader to hack some JCL, COBOL or FORTRAN. :D.

      • Re: (Score:1, Informative)

        by Anonymous Coward
        Someone is bound to point it out, so it may as well be me:

        Korea War ended in 53.
        Vietnam War ended in 75.

        • Re: (Score:3, Informative)

          by nuzak ( 959558 )
          Technically the Korean War never really ended, there's just been a 50+ year ceasefire. We tend to not draft people when there isn't any shooting going on though.

          • Re: (Score:2)

            by PCM2 ( 4486 )

            Technically the Korean War never really ended, there's just been a 50+ year ceasefire.

            Well, technically it wasn't even a war. It was a "conflict," or perhaps a "police action." It was never declared by Congress.

    • Indeed the seventies were crap. The sixties were groovy. man.

    • Re: (Score:2)

      by rnturn ( 11092 )

      `Startup plays "Disco Inferno"'

      Good Lord! I lived through the Disco era. It was far from Groovy, believe me.

      `Comes with a draft notice for assignment to Korea'

      Anyone from the '70s (well the early '70s, anyway) would have thought that an assignment to Korea after getting drafted wouldn't be so bad. Better than shipping out to 'Nam, anyway.

      • Re: (Score:2)

        by hey! ( 33014 )
        Geez, don't tell them that. Whenever a kid asks about the 70s, I tell them, "Well, on one side, everyone had to wear bell bottoms. But on the plus side, there weren't any veneral diseases that anybody heard about that that couldn't be cured with penicillin, so everybody got all the sex they wanted."

        Keeps them from pitying you for being an old, obsolete codger.

  • This is only slightly more interesting than... (Score:5, Funny)

    by dotancohen ( 1015143 ) on Wednesday February 28, 2007 @03:34PM (#18185674) Homepage
    ...than the Hip Hop programming language. # include numba main { hollar ("Wassup, world!"); giveItUp 0; }
  • Groovy. [impossiblefunky.com]
  • The computer world is running out of names... when I saw "Groovy", I thought of the engine used in The 7th Guest and 11th Hour. (sorry, cant find the links anymore).
  • Caution: Mildly flamey (this is liable to really wind some people up, but I'm sure as many will agree :-)

    I don't know where people get the idea that coming up with a new incrementally different languages and ever mote elaborate frameworks, when we have a large number of functional ones already is worthwhile endeavor (outside of academia and research labs). IME, "agile programmers" (the 'paired programming', 'what radical new methodology can we hop on board with this week' variety) are the worst offenders of
    • Oh dear.

      you are missing the point about so many things I am just tempted to say *Whooosh* and have done with it.

      From your tone you sound like you think you are a good programmer and yet your opinions indicate that you have a real lack of experience.

      If you are young and new to development - leave your current job. Tomorrow. and go into the world and get some more experience (this is assuming you want a career of some sort). If you are old and cynical stick with it and hope that there is enough work in whatev

      • Re: (Score:2)

        by @madeus ( 24818 )

        you are missing the point about so many things I am just tempted to say *Whooosh* and have done with it.

        From your tone you sound like you think you are a good programmer and yet your opinions indicate that you have a real lack of experience.

        Given the level of inaccuracy of your first statement, you'll forgive me if I don't put much weight in your second. ;-)

        While I'm not an old man by any stretch actually I have quite a bit of experience (long enough to have a five digit /. UID in at least, which is far from impressively low but it's pre .com at least :-), and I get to design and develop some pretty interesting software (for a household name, for a customer base of millions). I'm pretty sure from my own experience and level of demand for work

    • I wondered about why someone would go to all the effort of developing Groovy, and I think it comes down to this: there are Java developers who are fond of the JVM, but don't much care for Java (or at least, not in all situations; maybe static typing gets them down sometimes). Groovy (and JRuby, and Jython) gives them (let's say) dynamic typing without leaving the JVM, with its wide range of libraries and pretty damn good platform independence. You can -- in principle -- drop a few jar files onto your clas

    • Re: (Score:3, Informative)

      by puppetman ( 131489 )

      I'm not familiar with Groovy - I was came across Bean Shell first, and the reviews at the time found it better than Groovy. Not sure if that has changed or not.

      That said, Groovy and Bean Shell are interpreted scripts written in Java. No compiling to byte code. I look at a Bash script (or PERL script) and often wonder what the developer was smoking when they wrote it. Bean Shell/Groovy are a way to get the power of Java without the overhead (no "static void main (String[] args)") - you can do all those handy

      • Re: (Score:1)

        by erinol0 ( 698793 )
        I did the opposite--I tried Groovy first. And it's fine as long as you don't mind huge memory leaks. Granted, this was a year ago, but there was a problem with the Groovy class loader iirc. At the time, the developers weren't very interested in dealing with this problem, and I even invested some time in trying to fix it, but it was a fundamental flaw in the class loading. We switched to Beanshell, and haven't looked back.
      • That said, Groovy and Bean Shell are interpreted scripts written in Java. No compiling to byte code

        Thats wrong, most scripting languages on Java are compiled to byte code and later Jitted. and this particular 2 are compiled to byte code, definitely.

        angel'o'sphere

        • Sorry, you are wrong about BeanShell:

          From the wiki: [ikayzo.org]

          Question: Does BeanShell reparse scripted methods on each invocation?
          Answer: No. Scripted methods are parsed once and stored in a parse tree. Reparsing can be forced by calling the source command.

          Question: Can I compile my beanshell scripts?
          Answer: There is currently no full bytecode compiler for BeanShell scripts, although one may exist in the future. In the mean time, there are ways to compile BeanShell scripts to Java classes that use the interpreter at
          • Oh,

            thats interesting, strange that I use BeanShell since 4 years or more and never saw this. I check next days.

            The source of the compiler and especially the code generator contains lots of byte code generating classes ... for what are those god for then, strange indeed.

            angel'o'sphere
            • I checked again.

              The wiki is wrong. BeanShell uses this library: http://asm.objectweb.org/ [objectweb.org] to create byte code.

              angel'o'sphere

              • I think you're mis-interpreting what ASM is being used for:

                From the URL you posted:

                "ASM is a Java bytecode manipulation framework. It can be used to dynamically generate stub classes or other proxy classes, directly in binary form, or to dynamically modify classes at load time, i.e., just before they are loaded into the Java Virtual Machine."

                I believe BeanShell makes some dummy stubs that are then dynamically modified at run time to the contents of the BeanShell script. Thus ASM. I found a reference to this

    • Re: (Score:1)

      by ady1 ( 873490 )
      With all the new cores/gpus available and programming getting complex everyday, we do need much more optimized and easier to use languages.
      • With all the new cores/gpus available and programming getting complex everyday, we do need much more optimized and easier to use languages.

        I am a huge fan of easier to use (and more specifically, maintain), and more 'automatically optimized' languages.

        I think Java's syntax (copied by everything from C# & VB.NET and PHP - you write eerily identical code in all four now) is actually pretty great, that doesn't much to do with the efficiency of the implementations though (when it comes to multi core systems

    • Re:Lets invent yet another language! (Score:5, Informative)

      by Joey Vegetables ( 686525 ) on Wednesday February 28, 2007 @04:36PM (#18186640) Journal
      Groovy is not "just another language" competing directly, in the same space, with others. It tries to fill a specific niche that, at least arguably, nothing else filled well, if at all: the ability to do high-level scripting, a la Python or Ruby, targeting the Java VM, and thus being able to inteoperate well in both directions with the Java class library as well as existing Java code. (Note: BeanShell was an attempt to fill a similar niche, but I'm not sufficiently familiar with it to know how well it did so. Jython and JRuby are other attempts, but are mostly existing languages implemented for the JVM, not new languages specifically designed for the JVM environment.)
    • That is a REALLY long post to write without knowing what you're talking about.

      (mildly flamey right back at you :p)

      Okay, okay, some substance to my post:

      You talk about "this sort of thing" and "this sort of stuff", which shows pretty clearly that you haven't used Groovy.

      I've used Groovy. I don't really like it, but I use Ant heavily at work, and you run into Ant's limitations very quickly. Being able to use Groovy from within Ant - once you're already within an environment that heavily uses Ant for automat

      • Re: (Score:3, Insightful)

        by @madeus ( 24818 )
        That is a REALLY long post to write without knowing what you're talking about.

        I think I know about developing software, YMMV. 8)

        You talk about "this sort of thing" and "this sort of stuff", which shows pretty clearly that you haven't used Groovy.

        It's just a collective term for systems and behaviours being advocated that I'd just described. What infers that I haven't used Groovy is my lack of descire for for Yet Another Programming Language / Framework (specifically, when those new languages frameworks are o
        • To each his own then. I understand your dislike of hype, and fatigue with learning new languages/frameworks that do the same things in slightly different ways.

          What I DON'T understand is dismissing Groovy outright because you have no use for it. The right tool for the right job... Groovy isn't the greatest thing since sliced bread, nor will it take over the world, but it does fill a niche that some people find useful (and I still think comparing it to a laundry list of the mainstream languages is missing t

          • Re: (Score:2)

            by @madeus ( 24818 )
            What I DON'T understand is dismissing Groovy outright because you have no use for it.

            In my defense, I'm not outright dismissing or attacking Groovy itself, I'm merely highly skeptical of the suppose benefits of the culture of 'lots of specialist niche languages/frameworks' as I personally feel the sheer number is more harmful than beneficial (certainly when teams decided implement particularly "niche" tools that their team happen to think are 'awesome', but that aren't widely known or supported).

            This is int
  • Why does this sound more like a porno flick than a scripting guide..

  • So Goovy is like Mondad, I mean PowerShell, I mean PERL ripoff for Windows but not M$'s proprietary system? Groovy, I'll have to try that out.

    Could somebody in the know let me know if Groovy has the flexibility of PowerShell? Thanks in advance.

    • no, not really (Score:3, Informative)

      by idlake ( 850372 )
      So Goovy is like Mondad, I mean PowerShell

      No, PowerShell is a shell, as the name suggests, and is based on the CLR. Groovy is a compiled language for the JVM.

      I mean PERL ripoff for Windows but not M$'s proprietary system?

      Well, no, Perl is a weakly-typed scripting language.

      I'm sorry programming languages are a blur for you, but there are big differences between them. Groovy is a god-sent for the Java platform, given what an awful language Java has turned into. Personally, I have no use for either Perl or
      • Personally, I have no use for either Perl or PowerShell, and I think both of them have serious problems.

        For particular applications, yes. Perl's a poor choice for writing an OS kernel, and Java's not a great choice for a simple command-line text processing tool. Both Java and Perl are good for web development, though it's easier to find web developers familiar with Java. No language is a perfect fit for every job. For many applications, Perl is a great tool.

        In a nutshell: use the right tool for the
        • No language is a perfect fit for every job

          That's true but not relevant. What I'm saying is that for every software development job, there is a language that's better than Perl. Perl had a good run and it was far better than shell+awk, which it replaced, but by now, it's obsolete and there are better tools. The only thing that keeps the language going is inertia and a few libraries that haven't been ported to other languages.

          I mean, come on, look at the "upcoming" release. Is anybody waiting with bated b
    • How did I get marked down as flame bait? Thanks for the responses, honestly I wanted to know if I could use Groovy to script the very few things that I need to because I'm not allowed to install PERL on this Win2k3 box.

  • Reminds me of that other book (Score:4, Funny)

    by Bitmanhome ( 254112 ) <bitman AT pobox DOT com> on Wednesday February 28, 2007 @04:19PM (#18186392)
    Ironically, "Groovy Inaction" is the canonical book on accomplishing nothing at all.

  • Back in the old days? (Score:5, Funny)

    by Jekler ( 626699 ) on Wednesday February 28, 2007 @04:27PM (#18186500)

    Interesting how 2005 is now being referred to as "the old days" and 13 months is referred to as "an eternity". Personally I would've gone with "not too long ago" or "just before last year's taxes were due."

    Sorry, I've gained a bit of perspective. I wrote the preceding paragraph back in the golden days of typing, in the age prior to taking a sip of my Mt. Dew, but I'm no longer posting in the same world it was back then.

  • You could say that I was a late developer (pun intended).
    Are you suggesting that you program from beyond the grave? You, my friend, are the Tupac of software developers.
  • Anyone? Noone? OK, fine, I'll throw it out there, but I know you're all thinking it! :)

    Groovy in Action Always, or GinAA.

  • Slashvertizing in Action (Score:3, Funny)

    by jb523 ( 220004 ) <jd.junk1+slashdotNO@SPAMkurutta.net> on Wednesday February 28, 2007 @04:35PM (#18186618) Homepage
    Summary:
      * Groovy is in Java, and therefore current and former Java programmers will love it (wtf?)
      * Groovy is a dynamic language and therefore attractive to people who work in scripting languages (wtf?)
      * Grails is implemented using Groovy and therefore Ruby on Rails programmers will be interested.
      * Groovy is awesome!
      * This book is awesome!

    I've seen a lot of advertising masquerading as book reviews on slashdot, and I don't generally mind 'em too much, but this one's over the top. The author seems to think that the book will appeal to every group of people that could possibly be touched by some aspect of Groovy, and gives very odd reasoning for each case. The review imparts almost no information beyond that and a summary of the table of contents. If the book is half as proselytistic as this review, then it's unlikely to be worth the paper it's printed on. Then again, you shouldn't judge a book by its review.

    My favorite sentence is:
    "I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it."

    • Re: (Score:2, Insightful)

      by Ikari Gendo ( 202183 )
      This type of aggrandizement and posturing is typical of the Groovy community. See a recently derailed EclipseZone thread [eclipsezone.com]. Some sample Groovy-speak:

      Groovy is unique in its ability to integrate with Java at the syntax, object model and API level.

      Vague platitudes and drivel. Meanwhile they can't even get a simple definition of "closure" right, to say nothing of a parser that doesn't make Perl's interpreter look like a Scheme reference implementation.

      • Re: (Score:2)

        by kaffiene ( 38781 )

        This type of aggrandizement and posturing is typical of the Groovy community. See a recently derailed EclipseZone thread [eclipsezone.com]. Some sample Groovy-speak:

        Groovy is unique in its ability to integrate with Java at the syntax, object model and API level.

        Vague platitudes and drivel. Meanwhile they can't even get a simple definition of "closure" right, to say nothing of a parser that doesn't make Perl's interpreter look like a Scheme reference implementation.

        uh, maybe you're just a bit slow then, because that sentance made perfect sense. It's saying that Groovy has similar syntax to java, uses the same APIs and shares the same object model within the JVM.

        What part of that was confusing to you? Not only was that perfectly clear, it was also quite relevant to Java programmers (and no, I don't use Groovy at all)

        • Mostly the fact that it's a lie? Javascript Rhino has been around for quite some time, to say nothing of BeanShell et al.

          • Re: (Score:2)

            by kaffiene ( 38781 )
            Uh... no.

            Java classes are second class citizens in Javascript and Groovy is compilable unlike Beanshell (the bit about the same object model as Java), so they have a point.

  • a scripting language that targets the java vm !? (Score:3, Interesting)

    by bcrowell ( 177657 ) on Wednesday February 28, 2007 @04:40PM (#18186676) Homepage

    To me, the java vm seems like the natural choice for a gigantic, mission-critical, server-side application that you start once and then allow to run without restarting for a long time. I don't understand why you'd want a scripting language that targets the java vm. Starting up the vm, and loading all its libraries, takes time, and for a typical application of a scripting language, that time could easily be an order of magnitude more than the time it should take for the code to run. Also, you don't get the benefit of JIT compilation if it's just a script that runs, does a job, and exits. Of course I realize that scripting languages aren't just for the kind of thing that unix shell scripts can do, but really, that's a major part of a scripting language's natural niche. Also, part of the Unix Way is that you write lots of small tools that work together; but if each of those tools is starting up a java vm, and then maybe invoking ten other tools that start their vms, it just sounds like a recipe for horrible performance.

    I haven't used rails, and don't know anything about grails, but I assume that a rails or grails application runs as a cgi, with a new process starting every time a user does something in a web interface. As a user of web interfaces, the last thing on earth I want is a web interface that has to start up a java vm every time I click on a button to submit a form. As a webmaster, I also can't see that as a good use of server-side resources. Or is there some mechanism similar to mod_perl that allows you to avoid this overhead?

    OK, correct me if I'm way off base, here!

    • Re:a scripting language that targets the java vm ! (Score:4, Interesting)

      by fizzup ( 788545 ) on Wednesday February 28, 2007 @04:47PM (#18186792)
      Embed Groovy in your Java application to provide scripting extensions, and call the methods from inside your Java code.
      • Embed Groovy in your Java application to provide scripting extensions, and call the methods from inside your Java code.
        OK, seems logical. Are a lot of people actually using it for that? The review mentions "calling Groovy from a command-line," "writing automation scripts," and Grails for web applications. It doesn't mention the idea of using it as an extension language for java.

    • I don't understand why you'd want a scripting language that targets the java vm.

      Why? To run those tiny scripts from your giant business app or a heavyweight desktop app once it's all started up...

      JDK 6 even includes a new extensible scripting framework support [java.net] just for this very purpose, and ships with the Rhino JavaScript engine...

    • Well, it's a "scripting language", but it won't get started and stopped on every request like a Perl script in 1995. Groovy compiles to Java ByteCode, so the application server doesn't know you were naughty and didn't use a completely statically typed language.
    • but I assume that a rails or grails application runs as a cgi, with a new process starting every time a user does something in a web interface.

      yeah, this assumption is quite wrong. i don't know of *any* even remotely popular language targeting web apps that does this. (django, ruby, java, php, .net, you name it) this was proven not to scale over a decade ago. :)
    • Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.

      If we're concerned about using this against Perl [debian.org], Python [debian.org], PHP [debian.org], Smalltalk [debian.org] or Ruby [debian.org], using the great language shooutout benchmark [debian.org]*, Java is about on par, if not better overall based on CPU time alone.

      My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meani
    • 1) Basically any server application needs to run all the time.
      2) Starting the vm on a modern machine takes about 0.5 seconds.
      3) Loading a few MB worth of libraries of course takes time; in any language. J2ee servers are indeed huge. But then they also include a lot of functionality and actually most of the time it spends booting it is actually executing functionality rather than loading libraries.
      4) Groovy is compiled to bytecode. That means it is being JIT compiled. Which makes perfect sense in a server en
  • 'Groovy' is a 60's word. By the 70's it was only used in Archie comics
  • Let's see, runs under Java virtual machine, uses Java libraries and objects... Wouldn't that make it, um, Java?

    • Re: (Score:1)

      by Tupper ( 1211 )
      The Java libraries are large and useful. The JVM is widely deployed, reasonably fast, cross platform and garbage collected. These traits make the JVM a good platform.

      Java, the language, succedes as is a better C++ (for most purposes); but it still has large downsides. It's not duck typed and it doesn't have a class inference system. It's verbose; so people write tools to write Java, but the language makes that harder than it should be. Still, you end up with a lot of code generated (by the IDE or wh

      • Re: (Score:1)

        by tuxlove ( 316502 )
        I.e, it's a high level language implemented as a Java application?

        • Re: (Score:1)

          by Tupper ( 1211 )
          Java is two distinct things: 1) a language and 2) a runtime.

          The Java language is ok, but not great.

          The Java runtime is somewhat better: the JVM is faster than most and the libraries are extensive.

          The Scala (or Groovy or Beanshell) compiler is a .jar (a Java application in sense 2) that reads .scala files and creates .class files. Those class files are Java applications (again in sense 2).

          All these languages can also be interpreted. Other languages-- notably variants of ruby, python, scheme and com

  • Groovy was designed as a dynamically typed language that is compiled into the Java VM. Examples of scripting languages based on the Java VM are Beanshell, Jython, and JRuby. In terms of language features, the two kinds of languages may seem fairly similar, but Groovy should perform better than the scripting languages.
    • You'd think it would, but my experience says otherwise. Groovy to this point has concentrated on loose data-typing and syntactic sugar that make it conducive to scripting. The fact that it can directly instantiate Java classes in its classpath really makes it a powerful choice for administration scripts that run on your existing J2EE infrastructure. However, it lacks:

      1) Good debugging support, at least as of a few months ago. I still need to println all my debugging, and I can't trace into the Groovy source

  • JVM targeted languages reviewed comprehensively (Score:3, Informative)

    by tezza ( 539307 ) on Wednesday February 28, 2007 @06:12PM (#18187910)
    JVM Language Soko-Shootout [cabochon.com] includes a section on Groovy [cabochon.com]. Steve was not very impressed.

    He liked the NICE language [sourceforge.net] the best.

  • For reasons described above, I don't think Groovy will replace Perl anytime soon, but it might make a great teaching language. You can start out very simply and expand into GUI programming, web programming, and any of the other million Java library functions that exist.

    In fact, it might make a great replacement for Java. Features that really should've been there from the beginning are no easy to access (ranges, easy to use lists & associative arrays, reasonable string handling)

    Although you can start out simply in Groovy, I find some of the funky "iterator attributes calling code snippets declared in 'closures' " to be cryptic. Here's an example (basically from listing 7.23 of the Groovy in Action book, see http://www.benslade.com/projects/java/groovy/Listi ng_7_23_GPath.groovySelfDoc.html [benslade.com] for the full example):

    assert ['ULC'] ==
    invoices.objLineItemList.grep{ aLineItem -> aLineItem.totalCostLineItem() > 7000}.product.name

    I think this says:

    1. for the invoices list of invoice objects
    2. for the attribute of the invoice consisting of a list of line items
    3. for each invoice, for each line item in the list, search via "grep" (although it's not using regex's here)
    4. pass the line item into the {}'s via the "aLineItem" parameter (the "->" is the delimeter, weird)
    5. calculate the total cost of the line item via it's totalCostLineItem method
    6. if it matches the greater than condition then, take the name attribute of product attribute of the current line item and return it as a list to be tested by the assert statement.

    I'm just starting out so maybe it'll start to make sense to me later, but Groovy's more advanced features are definitely not for beginners or simple scripting applications.

    Ben Slade
    Chevy Chase, MD

    • Re: (Score:2)

      by Fweeky ( 41046 )
      I've never used Groovy, but it looks fairly clear to me (though I have a Ruby background), except the final bit looks like it should be *.product.name (which will apply .product.name to each element of the list to the left of the operator):
      1. send objLineItemList to invoices (returns a List)
      2. send grep to the List with a closure (returns a List containing each element for which closure(element) returns true)
      3. for each element of the List, send product, and to the return value of that send name (returns a list wit

      • Re: (Score:2)

        by Fweeky ( 41046 )
        Oops, add return(..) around the create_function bodies; no implicit return values in PHP.

  • My beef with Groovy (Score:5, Interesting)

    by feijai ( 898706 ) on Wednesday February 28, 2007 @11:11PM (#18190618)
    I believe firmly that new language should appear in the world butt-naked beautiful. Elegant, consistent, and with a good formal footing. They grow warts as they age, though some (like Lisp) have managed the wart stage with much more elegance than others (like C++).

    Here's the thing. As I've watched it, Groovy has appeared on the scene as a big giant hack. It's got a piecemeal formalism: it was clearly conceived originally by people who do *not* know how to make programming languages, and then as it somehow squirmed its way into a JSR it gathered the interest of people who *do* know what good languages looke like, and they tried hard to clean it up, but not entirely. And it's got HUGE numbers of ugly inconsistencies, compounded by a need to be approximately backward-compatable with Java for no particularly good reason (interoperability and sermantic compatability != syntactic compatability).

    And... it's slow. That's a big deal. Take kawa, for example, the leading Scheme system written in Java. Kawa has optional type declarations, and with them added in, it's about 1.5 times slower than Java. Without them, it's 10-40 times slower, more or less like Groovy. The point is that kawa, a language *totally* *alien* to Java semantics, is decently fast. Groovy, a language which is attempting to be a superset of Java, more or less, is *not* decently fast. It's not like you can't _make_ a fast Java language. Kawa did it. Groovy's a mess.

    There's my rant.

Slashdot Top Deals

"If there isn't a population problem, why is the government putting cancer in the cigarettes?" -- the elder Steptoe, c. 1970

Close