Second, when read sequentially, it is a good tutorial to the language. Sometimes there are two or three "recipes" that really build an interface around some common piece of code, and each of the recipes dutifully repeats the explanation of the common code. This happens only in the latter parts of the book, when the job of explaining the language proper is done, so it is easy to forgive.
As for Groovy the language, the light-weight syntax and automatic hiding of getter/setter methods is a very welcome improvement over Java; for me, the availability of closures alone is a good enough reason to prefer Groovy to Java. When viewed as a "better Java" (as opposed to viewing it as a completely separate language), Groovy does suffer from the ".NET disease", extending the language too far outside of the "philosophy" of the language into areas that should be in libraries or omitted completely, e.g. the way every "delegate" in .NET can automatically call more than one function. (This disease is by no means restricted to .NET - see e.g.
<tgmath.h>
in C, or enum
and other recent-ish additions to Java.) In Groovy, the methodMissing
feature and the ability to add methods to a class at run time seems to me far too different from the original Java object model.If you have used Java before and turned away with sore fingers and disgust, do look at Groovy; it may not be good enough to become your primary language, but it will make cooperation with Java software much more bearable. If only someone replaced the endless XML "configuration" in
.war
, .ear
etc. archives by something usable...