||Friday, January 23, 2004
I stumbled over Gregory's paper on Scriping Language Shootout
and just wanted to make a few corrections - already quite a bit of
information in this report is out of date and a few mistakes were in
there (understandable as the groovy documentation still needs more
work). Before I start its a little unfair to compare a project thats
not even had its first full 1.0 release with some other well used
scripting tools. Anyways here goes...
Our next stop was with CodeHaus and Groovy. We initially had an issue with
There is no build.xml file in the CVS tree. It looks like the Maven
tool has added it in there by default as part of the source code
release - we'll have to fix that. Thanks for the heads up. If you take
the latest code from CVS its not there, I promise you (nor has it ever
groovy because it has a build.xml file sitting in its build directory
that encourages you to use ant. This build.xml file is horribly broken
(including hard coded user specific paths even) and should be striken
from the CVS tree forever.
We then ran the maven build and we were incredibly
impressed by how maven not only started downloading all of its
dependencies, but also ran all of its unit tests. This was incredibly
impressive [^] if time consuming.
Thanks what binary distributions are for :). Only people hacking the
groovy implementation code need to use the Maven build - though of
course your welcome to use it too if you like. You can use your IDE for
What this means to us is that it is highly likely that
Groovy will be easy to support as a 3rd party package [^] and it actually
encouraged us to look into Maven for other uses down the line. Maven
may end up being a terrible product, but with such a good showing from
Groovy[^] it is certainly worth investigating.
Wow, Hani won't like that, people being impressed with Maven :)
Once we started trying to groove with it, however, Groovy
disappointed us on a few levels. The first is that it depends on the
horribly documented Bean ScriptingFramework in order to integrate with
No it doesn't! There's no reason whatsoever to use BSF uniess you are
already using BSF in your app and want to support Groovy via BSF like
any other scripting language. Only use BSF if you want to remain scripting language
You can use Groovy objects directly in Java code as they are normal Java objects.
You can use the GroovyClassLoader simply yourself to load classes/scripts as and when you want and keep them around for as long as you like.
Plus there's the GroovyShell for executing scripts / expressions directly in Java code without any BSF stuff nor do you need BSF on your classpath.
In addition, Groovy[base ']s own documentation isn[base ']t all that good at telling you what you need to do if you want to embed Groovy.
Agreed! Though for a not-yet-full 1.0 release is not that bad. But
you're absolutely right we should have a specific page on embedding
groovy to make it easier to figure out.
Nevertheless there is a BSF Integration section which
showed us how we should do it.... all one example of it. This left us
to our own devices to figure out Groovy integration with Java [^]
something we found none too Groovy.
We do exactly this with Groovy. I'm confused?
A note for other scripting language authors out there [^] BSF if
poorlydocumented. If you want us to embed your scripting engine either
provide usenough documentation on how to do so with BSF or do what
Jython and BeanShell do and hide it behind a façade.
The next letdown is that Groovy depends on a HUGE amount of
dependencies in order to work. I was amazed that the scripting engine
actually depended onmore libraries than our entire tool chain!
Again, please read the FAQ which has an entry on this. We depend on just ONE jar, ASM which is 19K.
The jars we use to do the build, test all the code, generate the
documentation from the wiki markup and unit test it all and create the
website is different to the dependencies required to embed Groovy.
Thanks for your comments Gregory; we hope we can make Groovy way easier
to use for folks by the time it gets to the full 1.0 release.
I'm pleased to announce the 1.0 beta 3 release of Groovy!
This release offers a large number of new features like subscript
operators on strings/collections/arrays/maps with backwards/forwards
inclusive/exclusive ranges, more core Java polymorphism, break
statement, ternary expressions, much improved autoboxing support and a
whole lot more. For a detailed list of all the changes in this release
please see the change log...
Whilst the language syntax is not quite frozen for the final 1.0
release its getting very close (we hope the next release to freeze the
syntax for backwards compatibility) and the projects codebase is
getting stable and solid now.
In addition we've also got a user guide now which covers getting started on groovy as well as documentation of all the new groovy-methods we've added to the JDK (thanks for the doc Guillaume! :). Also we've a tip of the day page on the wiki where we can brain dump interesting things we've discovered.
We've had some great feedback on the project so far,
particularly since the last release and we've hopefully managed to fix
all the gremlins folks have found. We've now got lots more test
cases and pretty good test coverage for the core language as well as
all the documentation unit tested to ensure accuracy (except on the
live wiki - we'll address that soon).
Warning: the online wiki is kinda stale and not unit tested yet - however all the documentation in the user guide is unit tested now.
There's been a huge amount of work put into this release and we've had
some great feedback and (most importantly!) test cases and patches
since our last release so a big thank you goes out to all those who've
Also a big welcome and thank you to all the new committers & contributors! :)
You can download the binaries and source code here...
Enjoy, and have a pleasant weekend everyone!
© Copyright 2007 James Strachan.