Groovy annotations: @TupleConstructor

If you use an inversion-of-control/dependency injection container like PicoContainer that favors constructor injection, you might have classes that look like this:

class Foo {

 Guh guh

 Keks keks

 Blorb blorb

 Foo(Guh guh, Keks keks, Blorb blorb) {
  this.guh = guh
  this.keks = keks
  this.blorb = blorb
 }

}

Notice the constructor only sets fields? Why should you have to write this glue code yourself?

Fortunately, since 1.8.0, Groovy has a @TupleConstructor annotation that removes the need for a constructor.

@TupleConstructor
class Foo {

 Guh guh

 Keks keks

 Blorb blorb

}

Behind the scenes, Groovy will add an empty constructor, as well as n new constructors, where n is the number of fields in the class. For the Foo class above, Groovy would add

class Foo {

 Foo() {}
 Foo(Guh guh) { … }
 Foo(Guh guh, Keks keks) { … }
 Foo(Guh guh, Keks keks, Blorb blorb) { … }

}

So, the next time you come across constructors that merely set some fields, replace them with @TupleConstructor.

Copy Properties or how to Clone a Class to a different Class

René has asked me how to copy properties/fields of an instance of one class to an instance of another class. I.e. you have

class A {
    int a
}

and

class B {
    int a
}

where B obviously does not extend A. You want to copy all properties of an instance of A to an instance of B.

Copy Properties

The solution is to access the properties property of A, filter it to remove the class and metaClass fields (which can’t be copied) and then use the GroovyObject#setProperty method on an instance of B.

class Copy {
	
	static GroovyObject copy(GroovyObject from, GroovyObject to) {
		from?.properties?.findAll { !(it.key =~ ~/(meta)?[cC]lass/) }?.each {
			try {
				to.setProperty(it.key, from[it.key])
			}
			catch (MissingPropertyException ex) {}
		}
		to
	}
	
	static <T> T copy(GroovyObject from, Class<T> to) {
		copy(from, to.newInstance())
	}

}

Clone a Class to a different Class

The code also lets you instantiate classes which is useful in case you want to clone an instance of A down its class hierarchy.

class A {
    int a
}

class C extends A {
 int foo
}

Calling

A someA = new A(a: 42)
C someC = use (Copy) { someA.copy(C) }

will give you a clone of A that is of type C.

Groovy programming with… with

The with method, which is added to all objects by Groovy, “allows the closure to be called for the object reference self.”

This sounds a bit complicated so here are some easy use cases for with:

Setting fields

Many APIs force you to do endless obj.setSomething(something) calls. In Groovy, …

keks.setFoo(someFoo);
keks.setRolf(copter);
keks.setFnuh(guh);

… becomes…

keks.with {
 foo = someFoo
 rolf = copter
 fnuh = guh
}

PROTIP: This works great with the JEE HttpServletRequest and HttpServletResponse classes.

Removing temporary variables

Conditional blocks in which you access another property of the same object can look like this

if (new File('rofl').exists()) {
 assert new File('rofl').length() > 0;
}

or you might be tempted to use a temporary variable

File f = new File('rofl');
if (f.exists()) {
 assert f.length() > 0;
}

neither of which conveys that it’s all about the file. Groovy makes this easier and more readable:

new File('rofl').with {
 if (exists()) {
  assert length() > 0
 }
}

Harmonizing API access

By going with with, you can turn any API, wether it’s fluent or setter-based into one simple, easy-to-read style.

Cleaner logging with Log4j, Commons Logging and java.util.logging

Logging frameworks are the Java programmer’s finger exercise — think content management systems for PHP programmers.

Most libraries these days use either Log4j or commons-logging, which is fine because SLF4J can replace commons-logging and redirect output from classes using either API to Log4j.

Problems only arise when the odd library uses the java.util.logging log framework. Not only is it initialized globally, it also can’t be replaced on the classpath because of its location in java.*. And its output is ugly.

With the public interest in Log4j, commons-logging and java.util.logging something like 100 : 10 : 0.5 (source: AdWords), not even Sun using the JDK for leverage can turn a mediocre also-ran product into a winner.

This means that java.util.logging must go. Thankfully, there’s a SLF4JBridgeHandler in SLF4J, but how to replace java.util.logging loggers with the SLF4JBridgeHandler?

import java.util.logging.LogManager
import java.util.logging.Logger

import org.slf4j.bridge.SLF4JBridgeHandler

class KillJavaUtilLogging {

    static {
        Logger log = LogManager.logManager.getLogger('')
        while (log.parent) {
            log = log.parent
        }
        log.with {
            handlers.each { removeHandler(it) }
            addHandler(new SLF4JBridgeHandler())
        }
    }

}

Now, simply mentioning KillJavaUtilLogging will redirect all java.util.logging output into SLF4J where it is logged using Log4j (or commons-logging, if you want).

class BlobFilter implements Filter {
    
    {
        KillJavaUtilLogging
    }
}

The corresponding Maven POM dependencies might look like this:

		<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2.16</version>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>slf4j-log4j12</artifactId>
			<version>1.6.2</version>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>jcl-over-slf4j</artifactId>
			<version>1.6.2</version>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>jul-to-slf4j</artifactId>
			<version>1.6.2</version>
		</dependency>