Groovy in Action 154
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.
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)
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.