techno.blog("Dion")

One of the great things about groovy is that you can sneak it into your development :)

So, go on, go to a project and tweak the build.xml to add groovyc into your compile step.

1. Add the ant task definition

<taskdef name=”groovyc” classname=”org.codehaus.groovy.ant.Groovyc” classpathref=”project.class.path” />

2. Go to one of your compile tasks and add a groovyc to do its thing (as well as the javac)

<target name=”compile-tests” depends=”prepare”>
<javac srcdir=”${src.tests.dir}”
destdir=”${build.tests.dir}”
debug=”off”
deprecation=”off”
optimize=”on”
includeAntRuntime=”no”>
<classpath refid=”project.common.class.path”/>
</javac>

<groovyc srcdir=”${src.tests.dir}” destdir=”${build.tests.dir}”>
<classpath refid=”project.common.class.path”/>
</groovyc>
</target>

3. Repeat for any compile tasks that you want to make groovy

4. Now, if you fancy, make a Foo.groovy instead of a Foo.java and away you go!

Congrats to James, Richard Monson-Haefel, and everyone involved with Groovy.

It was great to see that the JCP Approves Groovy Language JSR: Sun endorses language.

This really is a great precedent for the Java platform. There was a time where the JVM had a bunch of languages, yet Sun didn’t want anyone to know / help / etc. Sun had the “one language, many platforms” approach versus Microsoft’s “many languages, one platform” take.

Now we can move to “right language for the job, many platforms” which will be good for everyone. The funny part of it all is that in real projects we have always used many languages: Java, perl scripts, bash, cmd.exe, SQL, velocity, JSP, XML, etc.

It would be great if some of the JVM developers did some work on optimising for dynamic languages too.

It’s a Groovy day.

James talked about some cool new things from the Groovy world in: Using Groovy XmlRpc to talk to Confluence, NanoWeb, Groovy-Ant (Gravy!) and more.

If you are on the groovy list you start to see interesting thoughts popup on a daily basis. With this little JVM based dynamic language, people are able to re-visit their views on a number of things, and are coming up with new ideas.

Of course not ALL of the ideas will be great, but there are a few interesting ones. Jon and I had some fun talking about what AOP-like things could make sense with a dynamic language, and have to play around with those.

I also really like the Gravy (Groovy+Ant) idea. Ant works very well in small projects when you just have to do the usual: javac, copy, jar.

However, it is very frustrating when you start to play cames with setting properties and having if=”…” in targets to get certain behaviour. I used to use a Perl build tool in a past life, and although you may laugh (oh god. Perl) it was very flexible, straightforward, and let you do the right thing. Sometimes you need to do things in your build that are totally suited to a scripting language…. and Groovy will take care of this for you.

I wonder what good ideas people will come up with next week….

Kudos to James for apologising for Jelly. It is OK to try new tech and see where it takes you! :)

Cedric points out that just because the Groovy JSR was submitted DOESN’T mean that it will be accepted.

He thinks that Sun will probably turn down the JSR as they see it as a threat.

Personally I don’t see it as a thread to Java. In fact I see it as the opposite. One proof is in Cedrics own statements about Ruby.

Don’t get me wrong: I am a Groovy fan. Ruby used to be my scripting language of choice and over these past years, I have accumulated a certain number of Ruby scripts that are working really well, but right now, I can’t think of any reason to use Ruby when I have Groovy.

I feel exactly the same way. I really like Ruby, but I haven’t touched it recently… since I had Groovy at my finger-tips. It isn’t because Groovy is “better” as a language…. it is because I can now reuse all of the Java code that I have laying around. Even better than that, I can choose to write code partly in Java, partly in Groovy (again, as Cedric mentions wrt ejbgen.jar).

So, Groovy has actually kept me working MORE on the “Java Platform”. Does Sun care about the platform…. or the language? I know what one I would care more about.

I also agree with Brian when he says Get it right — Groovy is endorsing the JCP.

This is a two way thing….. and makes the JCP move towards being a valid standards organization, versus being Sun’s Java toy. If the JCP (and this ISN’T JUST SUN) accept this JSR, it will say a lot…. and all positive in my book.

Laszlo has written up some interesting thoughts on latent typing and micro-interfaces.

The dynamic vs. static debate is as eternal as vi vs. emacs (wait, or is it now IDEA vs. Eclipse), Microsoft vs. The Rest, ….

I find myself jumping around a lot between languages that enforce static types, and dynamic. When in one, I find times that I miss the other. Sometimes I *want* a strict interface, sometimes I want a looser one.

This is yet another reason why I like what I see with Groovy, as well as many other new languages. I can pick and choose, depending what I am doing. This is the way forward for me.

So it is good news that the Groovy language has been submitted as JSR 241. It will be quite an experiment to see a new language standardized via the JCP. There are many questions that people are asking: Is it too early for Groovy? Doesn’t it need to mature more? Will the JCP slow it to a crawl? Time will tell :)

Good luck James, RMH, and everyone involved.

Cedric has put together the simple API of Velocity, with the power of the Groovy language. The result is a new templating solution called Canvas.

I have actually been thinking about this exact problem, and think Cedric is on the right track. I think there will be a great trend to using Java + Groovy on projects, as there is a time and a place for each of them. Since they play so nice together it works perfectly.

On the templating site itself, I do have a pet peeve.

I don’t like the JSP-style syntax:

<% groovy code %>

I would prefer something more Velocity based…. and allowing simple:

Welcome $user.name

If the two were combined then you could have the best of both worlds.

I also hope that there could be an option: “don’t preserve newline at the end of tags” which would stop the following code:

Hi
<% do x %>
<% do y %>
There

from producing:

Hi

There

It just drives me nuts :)

Well done Cedric!

I have really been enjoying Groovy, and finally got it all setup in the dev environment for TheServerSide codebase. This enables us to whip up a .groovy instead of a .java and get to work. This is so nice as there are some tasks where having a script is so much nicer.

It took me a second to set this up correctly on the JUnit side.

Most people have the following batchtest in their ant scripts:

<batchtest fork=”yes” todir=”${junit.reports.dir}”>
<fileset dir=”${src.tests.dir}”>
<include name=”**/*Test.java”/>
….
</fileset>
</batchtest>

you simply need to check for .class files via the build dir instead. You can’t look for .groovy as the tests will be skipped:

<batchtest fork=”yes” todir=”${junit.reports.dir}”>
<fileset dir=”${build.tests.dir}“>
<include name=”**/*Test.class“/>
….
</fileset>
</batchtest>

In related news, Gerald Bauer (yeah, the Java Republic guy) just put up a presentation that he gave on Groovy. He doesn’t go on about freeing Groovy ;) He does sneak in references to XUL of course :)

Cedric talks about his desire to have real properties in Java, and points to Groovy’s Plain Old Groovy Objects which gives us the syntactical sugar.

I definitely agree with him, and also really like the named parameters that you see in the Groovy examples:

import java.util.Date
class Customer {
// properties
Integer id
String name
Date dob    // sample code
static void main(args) {
customer = new Customer(id:1, name:"Gromit", dob:new Date())
println("Hello ${customer.name}")
}
}

I have always liked named parameters, as I have seen many bugs due to methods such as: doFoo(String acct1, String acct2). Here we have no way to know if someone is passing in the right info (other than via Unit tests).

This comes up a lot more when you use primitives as arguments, and some people try to get around the problem by always using encapsulated representations… but that just doesn’t work all the time, and is an overuse of OO.

Groovy is just looking nicer and nicer.

Groovy Beans page