S Davis

You asked about three books, but allow me to mention 4.

GinA is written by Dierk Koenig, Guillaume Laforge, and Paul King -- all three contributors on the Groovy project (Guillaume is the tech lead). The forth author is Andy Glover -- an expert on unit testing. It does a nice job of presenting the best parts of the language directly from the mouths of the folks who wrote it. The metaprogramming parts are bit dated now with the release of 1.5 (more on that in a moment), but 85% of the book is still valid. There aren't plans to update this book until Groovy 2.0 comes out (realistically in 2009), so it is what it is for now.

For the most up-to-date, as well as IMHO the most comprehensive coverage of metaprogramming, DSLs, and the like, Venkat's new book Programming Groovy is the one to pick up. Venkat and I started writing Groovy Recipes together, but quickly realized that we were writing two very different (yet complementary) books.

Groovy Recipes is for busy programmers - just the code, ma'am. "How do I parse a RSS feed?" -- here is the code to do it, and here are a couple of paragraphs explaining what is going on. It's still a very readable book, but it is a tactical book whereas Venkat's is a strategic book.

Def Guide/Grails is a very good book -- Graeme Rocher is the author and the tech lead on the Grails project. It, unfortunately, is a bit dated as well. It was written in the 0.3 days, and Grails 1.0 just came out this month. There are plans afoot to upgrade it to 1.0, but you probably won't see that edition until Q4 of this year. The good news is the book is still more right than wrong. It's still the best place to take a deep dive into the technology. There is a new book coming out soon -- Practical Grails Projects -- that might hold you off in the short term until DGG ships.

We've got over 160 people here this week for the Groovy/Grails Experience. I'm _thrilled_ to see that level of interest.

There is plenty of Groovy/Grails content at the NFJS show every weekend in a different city (yes, even Austin!) Where G2X is a bit different is that we've been able to draw presenters in internationally. Graeme Rocher is here from the UK (tech lead for Grails), and we have folks in from Germany, Romania, and even Australia. That's a bit more problematic to do over a quick weekend...

If the interest remains high, we are considering a second G2X in the fall -- maybe on the left coast since we're in the DC area now. Stay tuned...

I just had James Weaver out to speak at the Boulder Java Users Group this past week. (You should see him if you get a chance -- he did a great job.)

I have zero hands-on with JavaFX, and have seen exactly two presentations on the material, so please consider the source. (Grin)

My take on JavaFX is that it has reasonably Groovy-like syntactically, but the push seems to be more for writing Swing-like rich GUIs. Groovy offers a SwingBuilder, but it is definitely more of a general purpose language -- not aimed or dedicated at GUI dev like JavaFX. I'd compare it more to Flash/ActionScript than Groovy directly.

I'm rather concerned that Sun's pushing JRuby

I wouldn't say that Sun is "pushing JRuby" so much as they are pushing dynamic languages on the JVM. JRuby gets a lot of buzz here in the states for two reasons --

1. Sun wants to make darn sure that everyone being even slightly tempted away from the JVM by Ruby's siren song has a good reason to stay. (Groovy doesn't so much draw people away from the JVM due to its strong synergy with Java.)

2. Charles Oliver Nutter and Thomas Enebo (the two JRuby leads that Sun hired) are based out of the US. The project lead for Groovy (Guillaume Laforge) is based out of Paris, and the project lead for Grails (Graeme Rocher) is based out of the UK. The contributors on these projects are based out of Germany, Romania, Australia, and, yes the US, too. Sun has contributed big iron hardware to the Groovy project for heavy load testing, and the Groovy DevCons are regularly held in Sun's Paris office.

Every success for JRuby, Jython, JavaFX is a success for Groovy as well -- rising tides raise all ships (where ships == dynamic languages on the JVM...)

I'll ask Graeme Rocher about it this weekend at the Groovy/Grails Experience. He's the leader of the Grails project.

As nice as GORM is, remember that there is a lot that we owe to being in a container -- Hibernate, Spring, etc. are all there and optimized to work together in a fairly constrained way. All of the magical GORM methods get dynamically added by virtue of the directory that the POGO is in, and so on. Taking any old POGO and making the persistence magic on it could potentially be a wee bit more problematic.

I'm not saying it's not a good idea, and I'm not saying that it wouldn't be awesome. I just think that GORM outside of a well defined container might be more problematic than what you see at first glance...

Two things jump to mind:

I really like the .each{} language feature. You can iterate over almost everything with .each, and where I can't I end up using metaprogramming to add an .each closure myself... (grin)

def languages = ['Java', 'Groovy', 'JRuby'] languages.each{ println it } ===> Java Groovy JRuby def name = "John" name.each{println it} ===> J o h n def today = new Date() ===> Wed Feb 20 21:13:37 MST 2008 (today..today+3).each{println it} ===> Wed Feb 20 21:13:37 MST 2008 Thu Feb 21 21:13:37 MST 2008 Fri Feb 22 21:13:37 MST 2008 Sat Feb 23 21:13:37 MST 2008


The other idiom / language feature I really like is shortening the "getter/setter" call to the field name. You are truly calling the getter/setter behind the scenes, but it cuts down on an _amazing_ amount of visual clutter:

def j = "Jane" println j.class ===> class java.lang.String System.out.println(j.getClass()) ===> class java.lang.String person.name = "Jane" person.address = "123 Main St" person.state = "CO"

I do not know what is Object scripting

The traditional answer is that "scripting" languages are not compiled. Groovy looks like it can run either way -- uncompiled or compiled. The secret is that it runs on the JVM, so it gets compiled either way. Either you type "groovyc" to compile it to bytecode, or the "groovy" command does it silently for you behind the scenes.

Doest this book contain the fundamentals of Groovy?

Yes.

Will this book help me, simplify Java, Java Enterprise development?

Yes.

Do you have any Table of Contents, sample chapter in this book?

Groovy Recipes

How many days it'll require to become thorough with Groovy?

How fast can you read? (wink) The book starts from the very beginning -- showing you how to install Groovy -- and gives you lots of code examples that you can run immediately.

The good news is that given the technologies you listed, all can do essentially the same thing. The bad news is that my answer doesn't help you much towards a conclusion, does it? (wink)

.NET is for Windows developers. If you are targeting that platform, it's something worth looking into.

Java is code that can run on any platform. It's strengths are really on the back end, although recent improvements to Swing and JavaFX are vying for their place in the sun on the desktop.

Groovy might be an easier way to get started than Java, but Java is more strict than Groovy. You might get frustrated learning Groovy first and then going to Java.

Ruby is gaining quite a (deserved) following, but it is clearly the new kid on the block. Most companies are still using either .NET and Java. The really forward thinking ones that live on the cutting edge are looking at Ruby, but for jobs right here, right now, .NET or Java are much safer bets.

I guess that it depends on your definition of "real world", doesn't it? (wink)

In my book GIS for Web Developers, I devote an entire chapter to a real-world scenario. We download a CSV file of US Universities. We then use Groovy to walk through the file line by line, pulling out the fields we need, make RESTful WS calls to a geocoder to get lat/lon points for our street addresses, and finally create SQL statements to insert each row into a database. All that in less than 200 lines of code.

So part of my "real world" usage of Groovy involves scrubbing data, staging databases, walking through XML files, CSV, log files, etc.

But I also use it on the enterprise side of things. AboutGroovy has been up and running on Grails since Dec 2006. All of my client engagements have been writing Groovy and Grails for the past two years -- ranging from major mapping application (ala Google Maps) to more traditional database skinning. Before that, I worked for a company that had over 100k lines of Groovy that offered Enterprise/Open Source support for Fortune 100 companies. Mutual of Omaha (a very conservative insurance company) has over 50k lines of Groovy code in production -- not in the periphery, but right in the middle of the actuarial department.

Oracle, Sun, IBM, SAP, JBoss have all announced Groovy support in their products.

Your question was a good one -- Groovy is anything but a marginal "toy" language.

Hi Trevor -- good hearing from you again.

Closures are a bit of a conceptual leap for Java developers. (Bear in mind that closures are due to be added to Java 1.7, so thanks to Groovy you're getting a bit of a sneak preview now... grin)

The easiest way to think of a closure is a freestanding block of code that isn't attached to a class. Things that you might consider making a static method on a utility class can be declared as a closure instead. So rather than the anonymous blocks of code we're used to seeing surrounded in curly braces after if statements, while loops, try/catch blocks, etc, can now be stored in a named variable and called at will.

All metaprogramming that you do involves closures. If you want to add a new method to a class, you create a closure and add it to the classes ExpandoMetaClass.

All of the "methods" in a Grails controller are, in fact, closures. Simply named blocks of code.

Here are a few links that might help:
Informal Guide to Closures
Formal Guide to Closures

1. Will Groovy replace Java in the future?

That's a bit like asking if frosting will replace cake in the future... (wink)

Groovy quite literally would not exist without the Java platform. It augments Java, not replaces it. That is what I find so refreshing about it. 100% of my legacy code is already Groovy-compliant.

Later, John Todd wrote:

In my very humble experience, Groovy (or any other JVM-compatible language) is hard to sell in Java workshops.

I can't argue with John's experience, but I find that statement odd. Groovy _is_ Java. I've had hard times convincing conservative Java shops to look at Ruby on Rails because it is a different language, requiring different IDEs, different deployment servers, different build processes, etc. But Groovy is a single JAR added to the classpath. Everything else about your development environment stays the same.

Now if John's experience is working with conservative organizations, I'm sure that he's had the same problem encouraging them to upgrade to Java5, or use Spring, or Hibernate.

If your organization prefers strongly-typed languages, then Groovy might not be an easy sell at all. Perhaps Scala?

In Groovy, method calls are dynamically dispatched. In Java, they are statically determined at compile-time. This is going to make Groovy slower in every case, although we are talking milliseconds here. If you are doing "real-time" Java (is there such a thing?), or some huge gagillion iteration loop of computationally intensive stuff, I'd look to Groovy. Of course, if Java isn't fast enough, I'd use C via JNI. If C wasn't fast enough, I'd use Assembly.

You can find micro-benchmarks that can prove anything that you'd like. In my experience as a web developer, the two long poles in my tent are DB access and HTTP response times. Hibernate tries to cache like mad on the DB side, and Apache HTTPD tries to cache like mad on the web side. Groovy has always been plenty fast enough for me in the middle -- I might be able to shave off a millisecond or two here or there, but nothing compared to the pain at the edges of the app.

FWIW, they are making huge performance gains in Groovy 1.6 (the next major release). They are caching dynamic calls so that they can be reused and presumably JIT'ed by the JVM. As I said, Groovy's already quite fast enough for my needs, so it'll be interesting to see what it's like after the next major rev.

The dynamic dispatch nature of Groovy really does make it more complicated than a traditional Java app -- I get vertigo standing at the top of stack-traces, looking down until I finally see a class that I wrote... (grin)

invokeMethod() and methodMissing() bring a lot of power to the developer. The multiple levels of indirection, unfortunately, make things more complicated at the bytecode level.

Adding Groovy support to a Java application is quite literally adding a single JAR to the classpath. If you are using WebStart, InstallShield, or any other utility to deploy your Swing application, it is already 100% Groovy ready.

And I agree with you -- SwingBuilder is a really nice, easy way to put together Swing apps.

If by "Web Services" you mean "SOAP", support is there but it's not mainstream. SOAP is reaching the end of its natural life (Google deprecated its SOAP services in 2006 in favor of REST; Yahoo! has always been RESTful to the best of my knowledge.), and that's reflected in many modern languages.

You'll find great support in Grails for REST and JSON "Web Services". There's an XFire plugin for SOAP, as well as plugins for RSS and Atom. I have an entire chapter dedicated to this broader, more inclusive definition of Web Services.

The good news is Groovy can use any Java library for SOAP, so you are in good shape there. The same is true for calling existing POJOs and EJBs -- Groovy can call Java seamlessly, and Java can call Groovy seamlessly. Groovy classes can implement Java interfaces and vice versa.

Groovy can quite literally do anything that Java can do because it _is_ Java.

1) What level of programming knowledge do you assume the reader already has?

I'd expect even a true beginner to be able to pick up the book and get something from it. Here's the problem, here's the solution. This book is more lab than lecture, so you'll want to look towards another book like Programming Groovy for deeper explanations of the subtleties.

2) Do I need to know Java to follow your book?

It'd be helpful. Groovy augments Java, so having some understanding of the Java ecosystem would be a good thing to have. I've never talked to anyone who's come to Java via Groovy -- I'd love to hear their perspective.

3) What is the scope of the book? In other words, how "deeply" does this book teach Groovy to me?

This book wasn't meant to be a definitive guide to Groovy. For that, I'd look to Groovy In Action. I think that my book hits all of the high points of Groovy, but it is by no means exhaustive.