Groovy, Programming

Low Expectations for the Build

I attended the talk on Gradle by Hans Doktor tonight and while I found myself agreeing that Maven is wholly unsatisfactory I did end up thinking that actually our expectations of build tools in the Java space are really low. What kind of things does Gradle offer us? Proper event interception, genuine integration with the build lifecycle, build targets dynamically defined at runtime, a directed cyclic dependency graph.

Looking at the list some of things you can’t believe are not part of our standard build package. We should be able to know when a build starts and stops and be able to attach code to those events. We should have decent target resolution that avoids duplication of tasks.

Gradle is head and shoulders about the morass that is Maven and is clearly superior to the ageing but faithful Ant but that it manages to be so on so little functionality is a shame.

Groovy, Java, Programming, Scripting, Software

Working with Groovy Tests

For my new project Xapper I decided to try and write my tests in Groovy. Previously I had used Groovy scripts to generate data for Java tests but I was curious as to whether it would be easier to write the entire test in Groovy instead of Java.

Overall the experience was a qualified “yes”. When I was initially working with the tests it was possible to invoke them within Eclipse via the GUnit Runner. Trying again with the more recent 1.5.7 plugin, the runner now seems to be the JUnit4 one and it says that it sees no tests, to paraphrase a famous admiral. Without being able to use the runner I ended up running the entire suite via Gant, which was less than ideal, because there is a certain amount of spin-up time compared to using something like RSpec’s spec runner.

I would really like all the major IDEs to get smarter about mixing different languages in the same project. At the moment I think Eclipse is the closest to getting this to work. NetBeans and Intellij have good stories around this but it seems to me to be a real pain to get it working in practice. I want to be able to use Groovy and Java in the same project without having Groovy classes be one of the “final products”. NetBeans use of pre-canned Ant files to build projects is a real pain here.

Despite the pain of running them though I think writing the tests in Groovy is a fantastic idea. It really brought it home to me, how much ceremony there is in conventional Java unit test writing. I felt like my tests improved when I could forget about the type of a result and just assert things about the result.

Since I tend to do TDD it was great to have the test run without having to satisfy the compiler’s demand that methods and classes be there. Instead I was able to work in a Ruby style of backfilling code to satisfy the runtime errors. Now some may regard this a ridiculous technique but it really does allow you to provide a minimum of code to meet the requirement and it does give you the sense that you are making progress as one error after another is squashed.

So why use Groovy rather than JRuby and RSpec (the world’s most enjoyable specification framework)? Well the answer lies in the fact that Groovy is really meant to work with Java. Ruby is a great language and JRuby is a great implementation but Groovy does a better job of dealing with things like annotations and making the most of your existing test libraries.

You also don’t have the same issue of context-switching between different languages. Both Groovy and Scala are similar enough to Java that you can work with them and Java without losing your flow. In Ruby, even simple things like puts versus println can throw you off. Groovy was created to do exactly this kind of job.

If the IDE integration can be sorted out then I don’t see any reason why we should write tests in Java anymore.

Groovy, Programming, Software

Using Gant to build Java Projects

I know I said I would be taking a step by step introduction to Gant in my last post on the subject but sometimes the devil drives and you need things done in a less systematic way.

Recently I have been building Java and Scala projects with Gant. I think it has been a successful exercise so I am just going to jump on and show you some example buildfiles. The first one is going to be a Java project. This project is obviously toy code but I think if you just download the sample project and start filling in your own code (it’s an Eclipse project, Intellij and NetBeans should both import it successfully) you will be happy with how little you have to change the build file.

First have a look at the Gant file itself and then I am going to talk about the things that I think make Gant such a powerful and productive tool. The first thing to point out is the line count, this represents a complete build file for a Java SE project in under 100 lines. That includes the Hello World target I’ve left in as an echo test. Gant might have a slightly weird syntax if you are unfamiliar with Groovy but it isn’t verbose.

Targets and dependencies were in the last post so this time the new thing is using AntBuilder. Any method call that starts with Ant is a invocation of an Ant task. These are nothing but thin wrappers around the normal Ant task (and in fact I usually write them using the Ant Task documentation). Things that are attributes in Ant XML become hash properties in the parameter list. Things that would normally be nested elements are calls to the enclosing builder.

One area where Gant wins big is the way you can mix normal variables, Groovy string interpolation and Ant properties. Declaring the directory paths as Groovy variables near the head of the file allows me to create new paths via interpolation and assign the variable to the properties of an Ant task. Ant XML has properties and macro interpolation but this is both clearer and easier.

I am also using the Gant built-in clean task and in the course of using it, Groovy’s operator overloading for lists. I’m not a huge fan of operator overloading but if it’s clear enough here then it is great to have a DRY list assignment.

I also like the way that the directories are created in the init task. This kind of closure looping over a list again shows some of the power and conciseness that can be achieved by a language rather than a configuration file. If you don’t read Groovy then the each method iterates over the list its attached to and each item resulting from the iteration is stored in the whimsical “it” local variable.

Groovy, Java, Programming, Scripting, Web Applications

Towards Groovier Projects

My latest project has witnessed an influx of Groovy. The project buildfile is run by Gant, there are Groovlets providing lightweight pages but it is in the test folders that the Groovy has made its most insidious advances.

Markup builder makes fragments of HTML to test, Groovy’s built-in Sql is beginning to setup and check the results of data operations at a functional level. Soon I plan to implement a Groovy Struts 2 result and then it will begin to replace Freemarker.

Groovy, Java, Programming, Scripting

A Groovy Dice Roller DSL Solution

I’ve been looking at Ruby Quiz 61 for a while and I decided to take a look at solving it in Groovy as well.

Here’s a rough draft of what a solution might look like. So what did I learn about doing DSL in Groovy?

Well overall I think the Ruby solution is probably more elegant but Groovy’s Categories make meta-programming easy for meta village idiots like myself. I really struggled at first though because the documentation is so poor. I had to refer to Groovy in Action to sort myself out.

The key issue was that a category must consist of static methods which have at least one parameter, the first parameter should be of the type you want to “attach” the method to (so in this example I want to add the method d to Integer). You then effectively form a closure on the block of code to be executed with the method use which takes a list of categories you want to have active in the block.

The Eval object acts as a kind of synonym for GroovyShell but is meant to remove the boilerplate. invokes the block with no pass-in parameters.

I think that Groovy does a decent job of providing solutions to problems like this but if you had a choice to make would you choose JRuby or Groovy? It ain’t easy. What I am convinced off is that both should be part of the library mix in any Java shop that is looking to the future.

Groovy, Programming, Scripting, Work

Using Groovy to create XML Schemas

I have previously found XML Schema to completely invaluable in defining interface points between systems. Normally file interfaces between systems are done in formats that are deceptively simple: CSV, structured text files. However in nearly all cases the initial simplicity tends to lead to a lot of problems. There is the issue of how to escape characters within your fields, particularly the field separator. The free text field is often used as exactly that, free text. Something is supposed to be a number field… until the letter X appears in it. Historical CSV is the worst as often the exact meaning and origin of each of the fields is undocumented and the meaning lost. I have even come across CSV generators that map meaningless constants to the output just to keep the number of fields the same. The receiving systems ignore those same fields or sometimes even hinge workflow off a value that will never vary in practice. The whole thing ends up being a nightmare.

Introducing an XML Schema reduces that nightmare but does bring in a lot more complexity. Being able to specify the type and order of the fields comes at a price. Previously when I have wanted to develop a new schema I have simply used the Xerces tools at the command line and an XML editor to generate both the Schema and a sample datafile. It works but it is quite laborious. Speeding this up would be great as often the point of capturing the complexity in the data transfer is so that the business or the architects can see the complexity of the integration and decide that they really want to do it before a lot of code gets written to integrate the systems.

Looking through the Groovy website I came across this example of how to validate an XML document and an idea is sparked. The multi-line indicator is a neat feature (borrowed from Python I think) and is (to my mind) a more elegant solution than the Ruby/Perl document syntax. It would allow me to define my schema, my sample document and my validation code in the same file. During iterations I would be more productive and when the interface is captured I just publish the final schema.

So I’ve knocked together a simple PoC and it seems to work pretty soundly. The easiest way to work with it is from the sample document to the Schema but TDD approach is to define the Schema and work back from the validation errors. The latter approach tends to avoid the situation where you’re validating your test document rather than your document template.

Groovy, Java, Scripting, Swing

Groovy Gridbag Example

Before Christmas I decided to give the Groovy Swing Builder a go since I am in the market for a language that makes creating small utilities in Java easier. Groovy is now Groovy 1.5, fully aligned with the Java 1.5 release. The new release sees lots of improvements all over the place. The Groovy Console has had a substantial revision and is now a really good way of experimenting with more complicated scripts (previously I only really used it to run snippets of code). The text colouring and decoration really works and the previous problems with massive stack traces obscuring actual issues seem to have been fixed. Really there are just two things that are needed to make it perfect, the first is line numbers so you can relate error messages back to the script you are working on and auto-completion. I wouldn’t mind having tabbed editors in the console as well but I can live without it.

What hasn’t changed is that documentation is generally woeful and examples and tutorials are hard to find. Most of the Swing examples I could find really used small numbers of components and simple Layout Managers. I have tried to create a more complex example using Grid Bag and based around some existing Swing code I found.

It took me a lot longer than I thought it would to create this code. Part of this is just not knowing how to tackle things, Groovy allows you to set attributes within the constructor with the interesting syntax property: value. However it is hard to know when you should use this or when the interaction should occur within the braces. After getting a working example going there is only one major mystery to me here. If I do not put the table inside the scroll pane then I lose the header columns on the table in the second tab. I really cannot see why that should be and if anyone more versed in the language can help me I would be grateful.

Groovy, Java, Python, Ruby, Scripting

Groovy or JRuby?

Martin Fowler blogged about the question a couple of days ago and ever since I have pondering that maybe it is not really the right question to ask.

I currently toodle between Jython, JRuby and Groovy for various reasons and I am an expert in none. The interesting thing I have found is that it is hard to pick one and just focus on that. To some extent they overlap heavily: they are all cross-platfrom, they are all dynamic, they all integrate with Java API stack I’ve committed to memory.

The first thing to say is that I am interested in scripting languages for prototyping and admin style scripting. I have never used Rails and the Grails data-model means that you need a specific kind of project to work on. If you want to use a particular product and that is only on one platform then that kind of makes your decision for you.

Each language has its own strengths, from my point of view I would categorise them in the following way. Jython has Python’s readability and solid language design, JRuby has Sun’s support, excellent community contributed library code and is very dynamic, Groovy is mini-Java, so it’s easy to learn and most importantly it has a functioning interactive console.

The last point might seem a bit weird, what about jirb and jython‘s interactive mode? Well Martin makes a very important point in his post about the purpose of these ports. Both JRuby and Jython aim to stay faithful to their source languages and be able to run code from their parent C implementations while expanding the API by accessing the Java libraries. Groovy on the other hand stays close to Java syntax and is the only one of the three that allows you to cut and paste code from a regular Java application and then play around with it in an interactive session. That is a very powerful and compelling feature.

Almost all the Groovy I do either comes from wanting to leverage or understand a piece of Java code.

All my Jython work on the other hand is about wanting to automate administration or manual tasks in a clear and concise fashion. Python’s dynamic data structures help, but so does zxJDBC the Jython specific database library that mixes DBI with JDBC to create a highly portable but simple database connectivity solution with no boilerplate!

JRuby on the other hand is something that only really comes up because Alpha Geeks love it. The syntax is gnarled and there is a significant learning curve before someone from a Java background can get “The Ruby Way” of things. The new integration of JRuby into NetBeans though makes developing in the language a comparative snap and I would suspect that JRuby will be a valid choice of application development language alongside Java now. The choice will be driven by the problems you are trying to solve not because one language is inherently “better” than the other.

Groovy, Java, Scripting

Groovy Experiences

So I tried to implement one of my little Swing Utility ideas this weekend in Groovy. I need the utility and I thought it would be good to give the scripting language a go beyond simply using it as an interactive console onto the Java SE API. This is what I have learnt so far.

Well first off having an IDE helps. I used Smultron on OSX as it is an open source editor. Usually I use Komodo Edit for scripting and man have I become lazy about closing my brackets and braces. Probably the number one issue with my syntax.

I like to have a book to hand when learning a new language and in this case I have been using Groovy In Action. It is a good book and certainly seems to fulfill the role I have when learning something new. It is concise enough to allow me to jump to a particular topic when stuck on a particular point but also seems to have been written in enough of a structured narrative to give a context to what is going on when you are more particularly stumped. I would recommend it if you are looking for something similar.

Groovy doesn’t have the easiest error messages to understand. For example this foxed me for a bit:

links.each {
link -> if(link.startId = anId) { items.add(getItemById(link.endId)) }

The error message is:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, /Users/rrees/Documents/dev/groovy/MindField.groovy: 37: expecting ')', found '=' @ line 37, column 28.
link -> if(link.startId = anId) { items.add(getItemById(link.endId)) }

However the error is that I am trying to assign a value in an illegal location. It’s that old classic of = versus ==.

When an error blows up the stack trace is huge and this can be extremely distracting when, for example, a unit test assertion is failing. Since I am on the command line at the moment this is unavoidable but it also happens on the console and rapidly you need to clear the console before the next run. I think the console should definitely collapse the stack trace so you see the Message of the exception and then expand the stack trace when you want to see it. Often the Assertion Message is all you need.

Talking of unit tests, I needed them more than normal because while Groovy is very similar to Java there are enough differences to make it important that you double-check your assumptions. Not using equals once was a bit weird for example. Also Groovy arrays seem to differ from the Collections API safe-zone. GArrays are like Lists but don’t seem to support the List interface, no isEmpty for example. list.get(0) doesn’t get you the first element, list.getAt(0) or just list[0] does. Most collection interaction seems to be modelled after Ruby in that you have to get with the closures to do stuff. For some reason I found it difficult to get what I wanted out of the closures in one pass and I tended to get something working with the unit test and then shorten the closure to something concise.

Ruby closures did not seem this hard but maybe it was because the whole language is new on me. As Groovy allows you to bring over the Java idioms you are used to perhaps there was impedance between something that felt familiar but actually required a different approach.

My closing experience was another positive, Groovy’s XML and Swing Builder objects felt incredibly powerful and easy to use. The syntax is tough to grasp but being able to play around with it in the console helped. Swing Builder in particular feels like it could be the way you should make all Java Swing apps.

Overall it is a pretty positive experience. In term of the competitors it felt much more familiar than JRuby but the result was not as neat as Jython scripts tend to feel.