Slashdot Log In
Groovy in Action
Posted by
samzenpus
on Wed Feb 28, 2007 03:21 PM
from the look-at-all-the-colors dept.
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.
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
obvious (Score:2)
Is this 'gina freely available in bookstores, or do you have to show ID to see it?
Not obvious enough (Score:3, Funny)
Re: (Score:2)
Doesn't that cover nearly half the population? (present company excluded, of course... this *is* slashdot, after all)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah, so what we really need is a group for owners, and a group for those of us that just rent.
Biased reviewer, reads like an ad for Groovy (Score:2, Informative)
Is Groovy a buzzword container class? (Score:2)
Hmmm, I wonder if it could be useful for teaching robotics on Lejos http://lejos.sourceforge.net/ [sourceforge.net] ?
70s were crap (Score:2)
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)
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)
Re: (Score:2)
Re: (Score:2)
Good Lord! I lived through the Disco era. It was far from Groovy, believe me.
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:3, Informative)
Re: (Score:2)
Well, technically it wasn't even a war. It was a "conflict," or perhaps a "police action." It was never declared by Congress.
This is only slightly more interesting than... (Score:5, Funny)
Trilobyte (Score:2)
Re: (Score:2)
When in doubt for links to 7th Guest and 11th hour info, there's always Wikipedia: http://en.wikipedia.org/wiki/7th_Guest [wikipedia.org] and http://en.wikipedia.org/wiki/The_11th_Hour_(comput er_game) [wikipedia.org]
Reminds me of that other book (Score:4, Funny)
Back in the old days? (Score:5, Funny)
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.
Now you've done it... (Score:2)
Groovy in Action Always, or GinAA.
Slashvertizing in Action (Score:3, Funny)
* 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)
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)
This type of aggrandizement and posturing is typical of the Groovy community. See a recently derailed EclipseZone thread [eclipsezone.com]. Some sample Groovy-speak:
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)
a scripting language that targets the java vm !? (Score:3, Interesting)
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)
Parent
Re: (Score:2)
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.
Re:a scripting language that targets the java vm ! (Score:2)
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...
Re:a scripting language that targets the java vm ! (Score:2)
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,
Dating (Score:2)
Re:Dating - Hey, it's the 60's (Score:2)
Second that. So he's even later than he thinks.
it's not a scripting language (Score:2)
Re: (Score:2)
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)
He liked the NICE language [sourceforge.net] the best.
Could Groovy replace Java? Some features cryptic (Score:3, Interesting)
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):
I think this says:
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
My beef with Groovy (Score:5, Interesting)
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.
Re: (Score:2)
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)
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. ;-)
/. 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
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
Re: (Score:3, Informative)
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:2)
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
Re:Lets invent yet another language! (Score:5, Informative)
Parent
Addendum (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:2)
Re: (Score:2)
Strings in Java do know how to capitalise themselves you dick / troll.
eg:
myString.toUpperCase()
Re: (Score:2)
Itself is Immutable (Score:2)
AC is just saying that there should also be a nonstatic method .toCapitalized() that would just force the first character ("Hello"). Nothing to do with immutability.
no, not really (Score:3, Informative)
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
Re: (Score:2)
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
Re: (Score:2)
Here's how I understand it: BeanShell was created as a 'command-line Java' useful in debugging purposes but pointless for actual development. Probably the same case is true for whatever Dynamic Java is. JPython is great, but you can't call JPython from Java, only the other way around. You'd naturally prefer to be able to call the scripting language from Java, because Java is a great language for defining the structure of a program and tedious for most coding.
I believe, but am not certain, that Groovy sol