techno.blog("Dion")

Imagine Maven talking to Jelly talking to Ant talking to Groovy :)

Jeremy Rayner contributed a nice Groovy Ant task, which we can piggy back on in Maven.

Guillaume Laforge put in the magic to make sure that the Maven POM is injected into the scripting engine, so you can play with $pom:

<project default="groovy" xmlns:ant="jelly:ant">
<goal name="groovy">
<ant:taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="maven.dependency.classpath"/>
<ant:groovy>
println pom.eachPropertyName{ println it }
println pom.name
</ant:groovy>
</goal>
</project>

It would be cool to be able to <ant:groovy script=”….”/>, or to write tags IN Groovy itself.

Of course, with m2 we will be able to write plugins with Groovy (as well as BeanShell and the like).

Brett Porter also talked about his addition to Maven to support CVS/SVN as a Maven repository itself. I personally am fine with using a traditional repository, where the http://….. is a SVN view itself, but I do hear people asking for exactly what Brett has implemented. Kudos Brett for doing this even though you won’t be using it yourself!

Lucene is one of my favourite opensource packages. I often find that I do need to ’script’ it so to speak, and Jeremy Rayner has shown how Groovy fits in.

He has taken some examples from Lucene in Action, and made them Groovy.

Very nice.

I am going through a slew of Groovy code and making sure it works in Groovy JSR.

From time to time it is nice to look at the grammar to see what is happening, and there is a hyperlinked version at: http://groovy.codehaus.org/jsr/spec/grammar.

My observations on the migration so far are:

• Get ready to do a s/// for: |\s*(\w+)\s*| to the -> version
• I am a fan of ‘#’ for comments, so I had to s|#|//|
• Get ready to do some ‘def’ additions although…
• I was surprised when a lot of scripts ‘just worked’ after the || conversion. I was surprised because I knew I wasn’t ‘def’ing all of my variables. It turns out that the current parser is fairly lax (apart from with member variables and methods), so I all of the following just works:
  

  aVar = "aVar"
  
  println aVar
  
  def m() {
  println aVar
  
  anotherVar = "anotherVar"
  println anotherVar
  }
  
  m()
  
  class Foo {
  def f = "letter f"
  
  def printF() {
  println this.f
  }
  
  def printG() {
  g = "letter g"
  println g
  }
  
  }
  
  fc = new Foo()
  fc.printF()
  fc.printG()
  

  The parser will get stricter though, so I will have to do def additions (I understand why, but I prefer not having the noise)

• I spent some time breaking things to see what errors came out. For the first time ever, I actually was pointed to where the problem was (with the correct line in script). Now I just wish they could surpress the huge stacktrace that occurs and just tell me the problem. Let me give a -option to see all of the evil crap.
• I know that I haven’t hit the hard snags yet though…. so we will see!

James and co. have released the first JSR based Groovy: groovy-1.0-jsr-01.

Now is the time to go through a bit of pain ;) and migrate old groovy scripts over.

Notable Changes

• Introduction of a def keyword
• Parameter separator in the closure syntax
• Safe navigation
• Property keyword
• Array creation
• float and double notation
• Explicit method pointer syntax
• No ‘do
  

One of the nice things about playing with Groovy is that I get some deja vu now and then, back to my Perl and Python days.

For instance, Jeremy Rayner showed us that a Classic Groovy trick is here in JSR Groovy:

Rather than the boring, repetitive:

Point p = new Point(2,5)

you can now do

Point p = [2,5]

This is because groovy will try to do a coercion of a List into the right type needed for the assignment.

It uses the list to choose the appropriate constructor, then invokes it for you. neat.

This then has the effect in most places, such as setters (e.g. for a property of type Point)

foo.point = [2,5]

and in named parameters

bar.setPointLimits(upper:[7,9], lower:[2,4])

And the really interesting stuff (to me) is that the empty list is coerced into the default constructor.

Date today = []
println "the time at the moment is $today"

is equivalent to

Date today = new Date()

I am not sure how much of a fan I am of taking the list syntax ([ ]) and making it have sideeffects, especially [] == empty constructor, but it does remind me of a pattern that was used a lot in the Perl days.

We used to fake named params by passing in Hashes, or references to Hashes a la:

do_foo(a => “hi”, b => 32)

So, I would love to see some syntax to enable me to pass named params in a simple syntax.

Something like:

Point p = [x:1, y:2]

foo.point = [x:1, y:2]

Of if you don’t want to hijack the syntax, you can do with a suggestion from John Rose:

Date d = (77, Calendar.JUNE, 28)

or:

Date d = (year:77, month:Calendar.JUNE, day:28)

Basically we are getting rid of the implicit new Foo(), and making an assumption from the type that we set. This is funny, as we have been getting rid of the implicit type all along (and potentially even in C# 3.0 [and therefore Java 7? :)]):

d = new Date(77, Calendar.JUNE, 28)

There are different cases. One for when you are passing in new objects to methods, and the other when you are creating a new object. Also there are the sideeffects of “I want to tell you this type”. Worth exploring… not sure how I feel about it all yet!

It was great to hear about Coyote:

The goal of this project is to develop a set of NetBeans modules to help developers write code in dynamic languages using the NetBeans IDE. Initially, we are targeting the the Groovy and Jython languages, but we anticipate a common framework allowing support for more languages.

The coyote is a quiet, efficient animal that thrives in urban and rural settings without any particular encouragement, and once established in an ecosystem, is virtually impossible to eradicate.

Getting completion and the like for Groovy is a god-send. This will have me installing NetBeans just for that development, although coyote doesn’t support 4.1 beta (which is actually VERY slick).

I wish this was in IDEA and Eclipse ;)

Tim Bray has taken a look back at his first year at Sun, and claims that Java is boring.

He isn’t trying to start a flame war.

Java isn’t boring for many people, and that is fine. It is also a good choice, as he claims, for many tasks.

However, I have to agree with him. PERSONALLY I find Java a little boring. Sorry. Coding in it is boring (I know, I know, if the problem is interesting then who cares about the environment? I do).

I can’t state how many guys who use Java for most of their day job say to me:

“Man, I wish I could get a paying job with Ruby”

These people are playing with Ruby in their spare time. Then they get to do a prototype in it, and then it spreads from there.

Although Java the LANGUAGE is boring, that doesn’t mean the platform is.

I hope that 2005 is the year of more expression in many languages on the JVM. Come on Sun, get in the game. Get more people hacking away on languages like Groovy to see where it takes us. Where is the Sun version of Comega?

Boring Isn