Calling Eclipse Ant builds from the command line

I usually use Eclipse for my software projects and I wanted to do Continuous Integration (CI), so after choosing a CI tool (I chose Hudson, a very powerful yet easy to use tool) I decided to make an Ant build file from my sample Eclipse project.

Even if you only want to make a very simple Ant task, like compiling and JUnit testing, a difficult problem will arise: the classpath. An Eclipse project can have a complex classpath, full of variable references (which are defined in the Preferences of your workspace), references to other projects, and so on. There are some Eclipse ant tasks in Eclipse itself that may be added, like projectBuild, and they take into account the classpath defined in the project, but when you try to add a JUnit task, you have to specify the classpath by hand in the task parameter. This classpath creation is tedious and time-consuming.

I thought it should be easier the creation of an Ant build from an Eclipse project, because the classpath information is in the .classpath project file. After googling a little, I found this great Eclipse Plugin, called eclipse2ant, which "tries to create a buildfile that matches the Eclipse project as close as possible". And it really works. I could very easily create an Ant build file from my Eclipse project, with the usual targets of compilation and it also exported my last JUnit runs! (the ones that you see in the "Run history..." menu of Eclipse).

All the classpath variables were imported in the Ant file, and I could execute the tests of my project without problems with Eclipse closed. Of course, you may want to tweak a little bit the Ant file to make it more portable or to organize better the variables, but with eclipse2ant you have a very good starting point that saves you a lot of time!

Happy continuous integration!


EnvyNG saved my day

A week ago I upgraded my Ubuntu Linux from Gutsy (7.10) to Hardy (8.04.1). All seemed to work properly after the upgrade. But then I saw a message in my desktop that notified me the driver I was using was a free one that was not able to manage the 3D acceleration of my card. It suggested me to activate the binary one from NVidia if I wanted those advanced features, so I did it.

When I restarted the system, my monitor was not detected and I couldn't use a high resolution screen (only 800x600). I tried to revert the change but it was not possible. Then I googled a little and could find this interesting thread, where I found a magical solution: EnvyNG.

I installed its GTK+ package (envyng-gtk) with Synaptic, executed its GTK+ app, followed the instructions of its wizard (very easy to use) and after a restart...voilà! My desktop works like a charm again !!!

The description of the EnvyNG package is:
"EnvyNG is an application written in Python which will download the latest ATI or NVIDIA driver or the Legacy driver (for older cards) (according to the model of your card) from ATI or Nvidia's website and set it up for you handling dependencies (compilers, OpenGL, etc.) which are required in order to build and use the driver."

To this brilliant programmer called Alberto Milone: thank you very much for making this great and elegant solution!


Unit testing mail code

If you ever need to write unit tests for code that includes sending or receiving e-mails, check this Java library, called GreenMail. It's easy to use and free (Apache 2.0 License) !

It supports POP3, SMTP and IMAP (even with SSL!!!). You can browse its website to see some examples, but this is a little sample to show you how easy it is to use it:


public void testSmtpCode() throws Exception {

GreenMail greenMail = new GreenMail();

// ... Your code that sends e-mails

assertEquals("body", GreenMailUtil.getBody(greenMail.getReceivedMessages()[0]));

public void testPop3Code() throws Exception {

GreenMail greenMail = new GreenMail();
MimeMessage message = ... // Build a javax.mail MIME Msg
User user = greenMail.setUser("to@localhost.com", "login-id", "password");

// ...Your code that reads e-mails and processes them

// ... Your asserts with the processing


The GreenMail server uses by default port numbers suitable for testing, not the usual ones in real sending/receiving, but you can change them if you want. The default port numbers are easy to rememeber, because they are the same as the standard ones prefixed by 3 (or 30 if the real port number has only 2 digits), so: the GreenMail SMTP server (standard port 25) uses a default port number 3025, the POP3 server (standard port 110) uses a default 3110, etc.

Happy testing !


The New Builder Pattern

The idea

I like to create immutable objects, especially after reading Josh Bloch's excellent "Effective Java" book. If an object is immutable, it has only one possible state and it is a stable one, so once you successfully build an object, you don't need to care about state transitions that can make your object unstable or corrupted. And immutable objects can be shared even in a multithreaded application. There are many other pros of immutability (you can read some of them here).

There is a classical way of making immutable objects in Java which consists of making all fields final (and private, of course), using only constructors to modify them (so that the only moment when a field is modified is during its construction) and making the class final (to avoid adding "setter" methods to subclasses). When you only have a couple of fields, that's fine, but when you have many of them you end up with a constructor with many arguments, which is ugly and difficult to use. If you have optional parameters, you can have a constructor with all the parameters and some other shorter constructors that have the mandatory parameters and some optional ones, that invoke the big constructor, like this:

public class Foo {

private final String mandatoryOne;
private final String mandatoryTwo;
private final String optionalOne;
private final String optionalTwo;

public Foo(String mOne, String mTwo, String optOne, String optTwo){
this.mandatoryOne = mOne;
this.mandatoryTwo = mTwo;
this.optionalOne = optOne;
this.optionalTwo = optTwo;

public Foo(String mOne, String mTwo, String optOne){
this(mOne, mTwo, optOne, null);

This can be a bit messy when you add more optional parameters, you end up with a lot of constructors like these and it has a lot of boilerplate code.The use of setters for the optional parameters is not an option, because this leads to non immutable objects (some object can change the state of your object with one of those setter methods).
Some time ago, thinking about this problem, I thought a solution could be to use a Javabean object, with one setter per field (even for the mandatory ones), but with a kind of "seal" method, that would "mark" the object as built and since that moment, an IllegalStateException would be thrown if a setter was called. Nevertheless, I wasn't very satisfied with this approach, because the setter methods that sometimes can be called and sometimes not would be confusing for the caller.

Then I found the New Builder pattern, explained by Josh Bloch in this PDF presentation, which is different from the original GoF Builder pattern. This pattern uses a public inner static class as a builder. The constructor of the original class is made private, so the only way to build objects is with the inner builder class. The builder has a setter method for each optional parameter and uses a fluent idiom that allows chaining of these method calls. I like this pattern a lot, because it solves the problem elegantly and effectively.

The implementation

In Josh Bloch's presentation there wasn't a detailed implementation of the pattern, although it was very clear the idea and the intention so I have searched for it in the Internet.

In Richard Hansen's blog you can find an implementation that seems to be more close to what Josh explains: the builder is a static nested class of the class from which it has to make instances, the builder's constructor is public (so you invoke the builder with 'new'), and the builder has the same fields as its enclosing class. The 'build()' method copies the content of the builder's fields into a new instance of the enclosing class. What I don't like about this implementation is this duplication of fields (for each field in the original class you have a duplicate field in the builder).

In Robbie Vanbrabant's blog there is a variation of this pattern, which avoids the boilerplate code using a base class for the builder and some reflection to build the object from the builder. I don't like the use of an interface for the builder, because that way you can't add a new optional parameter without breaking existing code that uses the builder (if you change the signature of a public interface the classes that use it have to change their code to implement the new methods). Update: This is not a problem at all, as Robbie points out in a comment. Also, I don't like the use of reflection because it's slower than the normal access to fields, but I do like the way it avoids duplication of fields in the builder.

The implementation I like most is the one found in Mario Hochreiter's blog. The builder is a nested public static class, but it changes the fields of its enclosing class directly, it doesn't use duplicates. It doesn't use reflection and the builder is a class, not an interface. The only problem I see is that, in theory, with a reference to a builder, you can change the state of the object it built, so you don't have the guarantee that the object is immutable. So I would add a check before each "setter" of the builder that would throw an IllegalStateException if the object has been already built and a check before the 'build' method itself to ensure the object is not built more than once. Also, I would make the mandatory parameters final. Update: I have made volatile the non final fields of the class in order to avoid problems of visibility if the reference returned by the method build() is passed to code to be executed in another thread, as Niklas points out in his comment.

So, with the example of Mario, I would implement this pattern this way:

public class ID3Tag {

private final String title;
private final String artist;
private volatile String album;
private volatile int albumTrack;
private volatile String comment;

public static class Builder {

private boolean isBuilt = false;
private ID3Tag id3tag;

public Builder(String title, String artist) {
id3tag = new ID3Tag(title, artist);

public Builder album(String val) {
if (isBuilt){
throw new IllegalStateException("The object cannot be modified after built");
id3tag.album = val;
return this;

public Builder albumTrack(int val) {
if (isBuilt){
throw new IllegalStateException("The object cannot be modified after built");
id3tag.albumTrack = val;
return this;

public Builder comment(String val) {
if (isBuilt){
throw new IllegalStateException("The object cannot be modified after built");
id3tag.comment = val;
return this;
// ... a lot more optional parameters

public ID3Tag build() {
if (isBuilt){
throw new IllegalStateException("The object cannot be built twice");
isBuilt = true;
return id3tag;

private ID3Tag(String title, String artist) {
this.title = title;
this.artist = artist;

The usage of this class would be:

ID3Tag tag = new ID3Tag.Builder("My Title", "My author")
.comment("Great song").build();

I have found a similar pattern, called the Essence pattern, described here and here by Dr Herbie. This pattern uses direct access to the fields of the builder (like in a C++ structure) instead of using "setter" methods and it doesn't use "chaining" of modifications like in the New Builder Pattern ("...builder.option1(value1).option2(value2)...").


Freemind 0.8.1 now works with Java 6

Freemind, this excellent mind-mapping open source application, has released a new version: 0.8.1. This is a bugfix release. The most important bug I would remark is that now Freemind works with the latest version of Java, Java 6 (before this release, you could use it with Java 6, but some options didn't work, like the Preferences dialog). I have also seen performance improvements in this release.


A very easy way to view dependencies: GraphViz

There is a wonderful and powerful tool called GraphViz that is able to draw graphs very easily. When I visited its website for the first time I thought it was very difficult to use, and this is completely false, so I will show how easy it can be.

This tool can do very powerful and complex graphs, but for the impatients (like me), that want to understand quickly how it works and be able to use it in another context (e.g. to show JAR dependencies in a Java application), I will show a very minimal example. Let's go.

First, you must download and install GraphViz. It is very easy to install. For Windows you have an installer, and for Linux you can use your favourite installer (at least Graphviz it's present in the Ubuntu Gutsy repositories, I don't know the other distributions).

Now, we will write a minimal text file with the dependencies we want to draw. Use your favourite editor and write a text file called 'sample.dot' with this content:

digraph g {
node1 -> node2
node2 -> node3
node2 -> node4

Now, you simply have to call the executable dot, from the GraphViz tool:

dot -Tpng -osample.png sample.dot

Pretty simple, isn't it ? We say we want to generate a PNG image (-T is the type of output file) and write it to an output file 'sample.png' from our graph file 'sample.dot'.

And the result is this:

Now, you can take a look at the documentation to know how to customize your graphs: you can specify colours, widths and shapes of your nodes, etc.

And one last advice: if the names of your nodes have spaces or special characters (like ':' or '\'), double quote them in the '.dot' file or you will get errors. So our last file would look like this:

digraph g {
"node1" -> "node2"
"node2" -> "node3"
"node2" -> "node4"

That's all. Enjoy making images of your dependencies!