Originally posted by Gregg Bolinger:
I could use my exising JDBC libraries, write tests and run JUnit, compiled the Groovy source into .class files and jar them up.
My question to this is, then why use Groovy? If you are going to compile to bytecode anyway, and jar them up, why not just stick with Java. When I think of using a scripting language, I think of it as an on-the-fly type of use. For example, I have an application written in Java. I would like users of my application to be able to extend it without having to recompile my code. Pretty much a plugin architecture, but with zero compiling. If that makes sense at all.
Aside from that, I'd assume a scripting language like Groovy to make a few things simpler with a simpler syntax. But again, my biggest problem is finding the niche for any scripting language.
How to use Grovy really depends on your application. For a large, real world Java J2EE app, the readability of the simpler syntax was huge in two important areas - collections and decimal math. Imagine a sales system where there may be more than one proposal, where each proposal consists of products that have configurable features. To calculate the costs, using BigDecimal, Groovy code literally looks like the following.
This is something that I can (and do) review with a business subject matter expert and it is relatively painless. With Java, you have to use the BigDecimal method calls such as add() and multiply() which make the code unreadable for anything non-trivial, even for expert Java programmers. Trying coding something like ((a * b) - (c * d)) / e in using Java BigDecimal and you find one Groovy's sweetspots. Notice in the code above, there setters and getters are implied in all of the calls and there are no type declarations, exeception handling or type casting this code.
[ December 13, 2006: Message edited by: Jim Yingst ]