Russel Winder's Website

GFontBrowser Updated to Version 0.1.3

It was irritating me that GFontBrowser didn't allow you to quickly display a font using gnome-font-viewer as is possible in Nautilus, so I added it. Double clicking a font does the job. See here for more on GFontBrowser.

Groovy and Grails User Group Meeting 2006-10-26

Paddy Gallagher, supported by Skills Matter, has started organizing some regular Groovy and Grails User Group meetings in London - at Skills Matter's premises in fact. He asked if I could do a talk on AntBuilder and **Gant** for last week's meeting, which I was happy to do.

Sessions such as these are not really the place for heavyweight presentations, so I talked around Gant code from real projects. Consequently, the slides I used have next to nothing on them. Nonetheless, people asked for them to be available. So you can get a PDF of the slides here.

For this talk, the main point was that using a dynamic programming language such as Groovy makes creating build systems so much easier. In the case of Groovy, there is AntBuilder allowing systems to be based on using all the ready-made tasks from the Ant library - and no XML, unlike with Ant and Maven.

Gant is basically an infrastructure framework around the AntBuilder, providing a command-line user interface and a ways of modularizing build scripts. Oh, and it provides an internal domain specific language to make Gant scripts look more like the classic Make, Rant, Ant, Maven type thing where there are targets that the system has to achieve.

If you are interested in a JVM-based build system, that doesn't use XML, but does provide the same sort of facilities as Make, Ant, SCons, Rant, etc. then take a look at **Gant**.

Gant vs Gosling

Justin Lee has created a build tool he calls Gosling(*) which he 'announced' here. Like Justin, I believe that XML is not a good language for specifying builds and yet the Ant tasks are a massive resource for build infrastructure. This is why I created Gant

I disagree with Justin when he says Java is good for describing builds. I think a dynamic language such as Groovy, is far better than Java for describing these things. SCons, Waf and Rant have shown that using dynamic languages and creating internal DSLs is the way forward for build systems. Unlike SCons, Waf and Rant, Gant does not (currently anyway) create a complete relationship/dependency graphs. Currently, Gant is a way of scripting Ant (and other, e.g. Ivy) tasks using Groovy, bringing in the power of using a general- purpose, dynamic programming language.

Justin presents a part of his build system for Gosling as:

@Default @Description("Builds the Gosling project") public void build() { new Javac(this, BUILD_DIR) .addSources(new FileSet("src/java") .addInclude("/*.java")) .addOption("-Xlint:unchecked") .addOption("-Xlint:deprecated") .addOption("-g") .execute(); new Copy(this) .setDestDir(new File(BUILD_DIR)) .addFileSet(new FileSet(JAVA_SRC_DIR) .addExclude("/*.java")) .execute(); }

Using Gant, this looks something like:

task ( build : 'Builds the Gosling project' ) { Ant.javac ( srcdir : 'src/java' , destdir : 'build' ) { compilerarg ( line : '-Xlint:unchecked -Xlint:deprecated -g' ) } } task ( 'default' : '' ) { build ( ) }

I feel that the power of Groovy's AntBuilder, and its harmony with the Ant XML labelling, makes Gant the tool of choice. Certainly I use it for builds where I would previously have used Ant. But then I would, wouldn't I.

(*) Even though Justin claims the original of the name Gosling is not derived from James Gosling's surname, it is a master stroke of publicity to use it. I hope the connection was intentional and not an accident.

Java Closures Get Groovy-er But...

Neal Gafter has released v0.3 of the Closures for Java proposal on his blog. The new syntax Neal et al. are proposing is:

{ int , int => int } plus = { int x , int y => x + y }

This is going to irritate people as they have to replicate the types of the parameters to the closure. Why not just let the compiler do the work and have:

{ int , int => int } plus = { x , y => x + y }

Of course, this is getting closer (or should that be closure!) to the Groovy syntax for closures:

plus = { x , y -> x + y }

or if you really have to have static types:

plus = { int x , int y -> x + y }

For now I shall stick with Groovy for closure-based programming.

Developing Java Software, Third Edition

Well, for various reasons, it has been a long time coming, but finally, it is here. Developing Java Software is now in it's third edition. My advanced copies arrived with yesterday and it should be in the bookshops (at least in the US and UK) next week.

This third edition is very different to the second in so many ways:

  • The overall scope of the book has been cut down so that it is better for use in 1 and 2 semester/term courses at universities. The material on algorithms and data structures and the ADS package has been taken out and will appear in a new book.
  • Test-driven development has been made a core feature of the whole presentation. We always did push the unit testing line, now it is absolutely 'front and centre'. We use TestNG as the unit test framework, as this looks destined to supplant JUnit as the de facto standard unit test framework.
  • Java SE 5.0 is assumed. We don't make a huge song and dance about generics and annotations, we just use them as though they have always been there, in a way we think is entirely suitable for people learning Java as a first programming language.
  • We have introduced material on Ant and Subversion so that people are learning about the tools of the trade at the same time that they are learning about programming itself.

We have set up a website to host support material associated with the book:

We are regularly adding more and more answers to the questions set in the book onto the website so that people have a reference. Feel free to send in answers to questions not yet answered, or alternative answers to the ones we have - we will ensure any submissions are attributed.

Thanks to Amanda Makepeace for painting 'The Forest Of Wic' which is the basis for the artwork of the book cover.

Java, Maps and Closures ( and Erasure )

On his blog, Neal Gafter has written about the for keyword that he is proposing for addition to Java to support closures. I am a great fan of closures and closure-based programming, so I like Groovy and Ruby. The declarative expression that is achievable with languages like these makes for short programs with fewer errors. In this sense, adding closures to Java seems quite exciting. However, I wonder if this is going to end badly, like the generics situation - I believe erasure has been, and continues to be, a bit of a disaster (I have written previously on this).

This makes me wonder if closures should actually be left out of Java and that more use should be made of Groovy and dynamic languages like it for creating JVM-based systems - after all Groovy is symbiotic with Java, not a competitor.

Neal starts with a Java method:

private Droid seekDroid ( final Map map ) { for ( Map.Entry entry : map.entrySet ( ) ) { final String droidName = entry.getKey ( ) ; final Droid droid = entry.getValue ( ) ; if ( droid.isSought ( ) ) { System.out.printf ( "'%s' is the droid we seek.%n", droidName ) ; return droid ; } } return null ; }

and proposes that a better way of expressing this is:

Droid seekDroid(Map map) { for eachEntry(String droidName, Droid droid : map) { if (droid.isSought()) { System.out.printf("'%s' is the droid we seek.%n", droidName); return droid; } } }

OK, a little bit less boilerplate (at the expense of a new keyword) but that is all it is. The example does not get to the heart of what closures should be used for. The above is still an explicit iteration construct, and the whole point of closures is to invert flow control completely. In Groovy the above can be written:

def seekDroid ( map ) { def droid = map.find { droid -> droid.value.isSought ( ) } if ( droid != null ) { printf ( "'%s' is the droid we seek.%n", ) ; } droid }

The point here is that the iteration is inside the find method that Groovy adds to the Map class (via its meta-object protocol). Neal says they do not want to add methods like this in Java because of incompatibilities with existing interfaces. He then proceeds to propose adding a method to java.util.Collections, which appears to be becoming the dumping ground for all the things people want but can't have due to backwards compatibility.

It seems then that backwards compatibility is going to drive all discussion of closures and Java, just as it did generics and Java. Generics only made it in to Java by ignoring all the parameterized type information at run time, i.e. we got type erasure. This is a horrible thing avoided by all other languages with parameterized types, C# for example.

It seems the fudges to get closures into Java are starting. Of course, it would be nice if Neal and co. find a way of doing it nicely and cleanly, I fear they will not, and Java will get messier. Personally I use Groovy, it already has what Neal wants to put into Java, cleanly and neatly. Case closured.

Gant - Building with Ant tasks and no XML

I like the features and functionality of Ant as a build tool but I really don't like XML. Also, having used SCons, Waf, Rake and Rant, I have come to believe that a build tool needs to be hosted on a programming language - SCons and Waf are Python-based systems, Rake and Rant are Ruby-based. Note here that Maven is a totally different sort of beast, not better or worse just different. Where Maven 2 is applicable it looks very good but there are situations where tools like Ant are applicable and tools like Maven 2 are not.

The obvious thing to me is to use Groovy as a base language for a build tool. Most of the work is already done of course, the AntBuilder class does almost all the work! However there is infrastructure needed to create a tool. Without such infrastructure everyone ends up building their own versions and there is nowhere for best practice to be reified.

In January I started an exchange on the Groovy User email list about this and there was some strong encouragement that having a pure Groovy script way of scripting Ant tasks in a framework would be a good thing. Over the last couple of week I have managed to put a start together for this. It isn't in release form yet but it does do the job. Gant can build and install itself in a Groovy installation. I also use it for building websites.

If you want to give it a whirl then check out the webpage here. Remember though this is not a finished tool it is a start to enable people to try it out and give constructive feedback so that it can evolve into a good and useful tool.

A Bash Completion Script for Rant

Recently I decided to give Rant a go having heard that it was better than Rake. Installing it on Ubuntu is a bit of a mission (well not really) - as the rant package only very recently made it into Debian Unstable, it isn't in the Ubuntu store just yet so apt-get doesn't do the job. Taking life in hands I downloaded and installed the Debian Unstable package and... it worked fine. The only problem is that there is no Bash completion script in the distribution. Easy to fix, write one. Having done one for SCons recently, taking the script from the rake package and amending it for Rant was relatively trivial. You can find it here.

Using a Vodafone 3G Connection as a Modem

Having got my P900 working as a modem, I thought - I just got a new phone for my wife and it is a 3G phone, I wonder if a 3G connection is any faster than a GPRS connection?

I got everything working with the Sony Ericsson v600i using both the Bluetooth and the USB cable and the speed is the same using either route and it is 3 times faster than GPRS.

I have written up some notes on my experience which can be seen here

Copyright © 2017 Russel Winder -