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.
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.
Re: (Score:2)
I was thinking "Very Awesome Groovy in Action", which would be somewhat more inclusive.
Finally, Slashdot links to Amazon (Score:1, Insightful)
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] ?
Objectivity and professionalism (Score:1, Flamebait)
Re: (Score:2)
Henceforth we shall only trust information sources with no first hand experiences.
Trade mags, here we come! (why is my hair getting pointy?)
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:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1, Informative)
Korea War ended in 53.
Vietnam War ended in 75.
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.
Re: (Score:1)
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:2)
Keeps them from pitying you for being an old, obsolete codger.
This is only slightly more interesting than... (Score:5, Funny)
Re: (Score:1, Redundant)
obligatory bruce campbell (Score:1)
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]
Lets invent yet another language! (Score:1, Troll)
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
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:1)
Re: (Score:1)
*hugs Java out of sympathy*
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:1)
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: (Score:2)
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
Re: (Score:2)
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
angel'o'sphere
Re: (Score:2)
The wiki is wrong. BeanShell uses this library: http://asm.objectweb.org/ [objectweb.org] to create byte code.
angel'o'sphere
Re: (Score:2)
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)
Multi Core / Multiple CPU performance (Score:2)
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)
Re: (Score:1)
(mildly flamey right back at you
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)
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)
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)
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
Re: (Score:1)
Hey, thanks for that, that's actually a sane reply that illustrates it's usefulness with a meaningful example.
That usage definitely makes sense to me (and worse - is not entirely unfamiliar!
Addendum (Score:2)
Weird title (Score:1)
Groovy Mondad (Score:1, Flamebait)
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)
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)
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
Re: (Score:2)
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.
Pun Understood (Score:1)
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)
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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)
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:1)
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,
Re: (Score:2)
Well, it's prolly not that bad. (Score:1)
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
Re:a scripting language that targets the java vm ! (Score:2)
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
Dating (Score:2)
Re:Dating - Hey, it's the 60's (Score:2)
Second that. So he's even later than he thinks.
Java? (Score:1)
Re: (Score:1)
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)
Re: (Score:1)
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
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
Re: (Score:2)
Re: (Score:2)
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:1)
Re: (Score:1)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1, Informative)
This blanket statement is trivially wrong. One day, you will look back and realize that you were quite naive.
Re: (Score:2)
Strings in Java do know how to capitalise themselves you dick / troll.
eg:
myString.toUpperCase()
Re: (Score:2)
Re: (Score:2)
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