This news is a bit belated by a few days but…. over the weekend, I spent some time getting the recently released Groovy 1.0 into the tree.
In case you hadn’t heard about it, Groovy is, among other things, a dynamic language that runs on the the Java VM. Some interesting data points about it:
- It’s dynamic, for reals.
- It’s about 98% syntax compatible with Java code (I made that number up, but really, it’s pretty durn close).
- Java bytecode gets generated at runtime, no need to compile.
- Groovy can generate Java bytecode to your typical .class files
A consequence of these points is that you can easily migrate from Java to Groovy, and have your project running exactly as it was. Then slowly, you can get into the swing of things, and take advantage of everything that Groovy has to offer as you get the hang of it.
One fear I’ve noticed of Java developers of jumping into a more dynamic language like python or ruby is late binding. You can’t really be sure the type of your objects until runtime. Sure, you can read the documentation (assuming it’s up to date) or peek at the code to be sure. With Java, binding occurs at compile time, so you can be sure that foo method expects a Bar, or that Bar has the aieeeee() method. I suspect some of this comes from defensive coding, where you become concerned about how your code will be (ab)used by others.
To combat this, a coworker and I have this idea… You use Java to define interfaces for the, uh, interfaces you care about. You can then use Groovy to implement these interfaces. By doing this, you get the best of both worlds: clients of your code get their strongly typed interface, and you get to do implementations with a more expressive syntax.
Overall, I’ve been pretty impressed with Groovy so far. Granted, I haven’t used it as deeply as possible yet, but it certainly has a lot of potential.
In case any of this sounds interesting, here’s some resources:
- The Groovy homepage, get your documentation on
- The recently released Groovy in Action
- The Disco Blog, by Andrew Glover, one of the authors of above mentioned book.
And in other Java dynamicism news, I’ve added the freshly minted JRuby 0.9.2 to the tree this past weekend as well. I haven’t played with it yet, so I can’t speak much on its behalf other than it’s an implementation of Ruby written on the Java VM. Perhaps that can be the topic for a future blog post.
Those points are nothing to do with Groovy. What is one unique advantage that Groovy has over — say — jython or jruby? The others are well-developed dynamic languages that have worked well for a long time, now, with the same bullet points except for syntax. And some of the most compelling advantages to those dynamic languages are escaping from the torturously-verbose syntax that java imposes. Groovy has just been a long painful road to bringing nothing interesting to the table.
Thanks for packaging it, though. Seriously. It’s good that people have options. And you, nichoj, are awesome, as this Gentoo-loving java dev knows from first-hand experience.
I just wish Groovy would stop wasting people’s time.
Granted, ‘being dynamic’ would apply to jython and jruby.
Being as similar as it is to Java syntax gives you a great migration path to start using it. This means you can mostly copy and paste a Java file into a Groovy file, fix a couple syntax errors (usually they are for loops, array construction, and annotations), and hey, you’re using Groovy. This isn’t to say that only this Java syntax is supported. In reality, you could say Groovy is a superset of the syntax, with plenty of less-terse-than-Java syntactical sugar that one would come to expect from a dynamic language.
Because it does generate bytecode, and can be compiled down to plain old class files. This is huge, as you can start using it in the middle of otherwise Java project.
Just did some fact finding, and it does seem like jython does that latter point as well. Regretfully, jython hasn’t been updated in a while, and it’s kind of stuck being at python 2.2.
JRuby is a much more active project (Sun having employed the two primary developers recently sure helps!). But, it doesn’t seem to sport that feature. You can only interact with existing Java code, ie you can’t extend the classes, and it doesn’t compile down to bytecode.
The java interfaces thing was also thought up by myself in implementing groovy @ my job. It is easier for the less agile guys to look @ the java interfaces. They also spell out exactly what inputs/outputs are needed and they help quell the overall uneasiness of some people to grasp a weak typed lang.
horray groovy! Here is one advantage. Not everyone is well versed in scripting langs. The guys on my project that want to start writing in groovy can immediately use things such as not needing to define getters/setters (therefore reducing the codebase, but doing nothing else fancy). Then they can write pure java for whatever they need and I can show them how to do redo some of the java they wrote in the groovy files. slowly and slowly, they become less dependent on the compiler and more dependent on documentation, api contracts, and elegant, concise code. It is an excellent tool for teaching people scripting whilst still having a language just as powerful as jython or jruby. again, horray groovy.
THanks a ton for getting groovy into the gentoo portage tree! I was using the rc ebuilds and was very happy to the 1.0 release out so quickly – much appreciated!
Any chance of you getting a grails ebuild into the tree – that would complete the link!
( Also – I notice the groovy ebuild requires sun-jmx, which, #1: has fetch restrictions, and, #2: is built into java 1.5 and greater, so not stricly needed if running groovy on a >= 1.5 jvm. Any chance of adding a -jmx USE flag for groovy or having the ebuild detect the java-config, and do the appropriate thing if >= 1.5? )
> What is one unique advantage that Groovy has over — say — jython or jruby?
* the syntax is much, much closer to java.
( there you go, one unique advantage, which was already mentioned in the blog that you’re responding to )
* compiles to java bytecode via groovyc, and therefore, once compiled thusly, becomes indistinguishable from a java class file
( jruby will have the above sooner or later, but currently groovy does this _now_ )
> Groovy has just been a long painful road to bringing nothing interesting to the table.
Painful? In what way were you involved with the development, design or implementation of groovy?
Brings nothing interesting to the table? Perhaps it doesn’t bring anything to your particular table, that’s fine, use something else.
> I just wish Groovy would stop wasting people’s time.
I wish people would stop wasting people’s time with useless comments. Your comment brings nothing interesting to the table. Name one unique advantage your comment has over other similarly negetive comments?
I prefer working with groovy over ruby or python because I enjoy its syntax much more. Plus I only need to learn _one_ standard library – the jdk. Plus I can go back and forth between java and groovy extremely easily with no discordance. Plus groovy has dynamic typing in addition to complete and optional static typing. Plus groovy is the second official standard language for the Java VM – the first being java itself. Plus after assesing both Ruby on Rails and Grails, I personally feel more comfortable with how Grails does things over Rails.
There’s already two books released on groovy and one on grails.
Groovy is more targeted toward java shops and programmers who want to have a seamless and transparent migration path to a fully object-oriented, dynamic language.
autocrat wrote:
Last time I looked, grails’s dependency tree has a number of things we haven’t even touched as far as packaging efforts go. Not to say it is impossible, but will take a bit of time and energy.
We’ve been using USE=java5 to mean ‘Use Java 1.5, and all the libraries that are available with it.’ This is used for at least tomcat. So that’s one option.
Another option is using mx4j for the jmx implementation. This is probably a better general solution, as it would let you use it with Java 1.4.