flexible closures in java with generics

with the upcoming of the new dynamic languages like groovy or ruby, functional programming seems to flow into developer minds of many. one key to it’s success is it’s mighty expressivenes when using closures. even in java world, closures are highly discussed now for future versions of the language.

by now we can use anonymous classes to simulate the behaviour of closures in a similar way, even not so powerfull as with the true lambda calculus behind the idea of closures. first of all, we have an interface named Closure, which ought to represent our code block:

public interface Closure{
    public Object exec( Object arg );
}

now if we have some classes which supports our closure …

public class BooksCollection{	

   private Book[] books;

    public Collection filter( Closure closure ){
         Collection filteredBooks = new ArrayList();

        for( Book book : books ){
             if( (Boolean) closure.exec( book ) ){
                filteredBooks.add( book );
            }
        }
        return filteredBooks;
    }
}

… we can simply define an ad hoc closure to filter some desired books:

Collection booksByGoethe = classcialBookCollection.filter(
    new Closure(){ public Object exec( Object book ){
        return ((Book) book).getAuthor().equals( "Goethe" ); } } );

this solution has some serious drawbacks: one of the strength of closures is it’s unbound and dynamic behavior to any kind of datatypes. you can pass a closure to any datatype who supports closures, where the closure is not restricted to a specific type of it’s arguments nor it’s return type. where you once pass an instance of type Book, you are free to use a closure to some other times, where you will pass instances of another type, let’s say Report. as you have seen in our simple example, in a half typed language like java you can achive a similar freedom by limiting the argument and return types to type Object. but this comes with a risky tradeoff.

1. loss of type safety
the compiler can’t check if your closure really returns an instance of type Boolean back to the BookCollection.
(the compiler can’t also check if the class BookCollection really passes only instances of type Book to the closure)

2. bothersome typecasting
in order to evaluate the passed Book and retrieve some of its properties inside of our closure, we have to cast from Object to Book.
same is true for BookCollection. we have to cast to Boolean in order to decide whether to adopt the current book to the filteredBooks or not.

well this was a somewhat humble solution … before generics.

generics to the rescue

with generics we can now define more flexible closures which exempt us from the bothersome work of typecasting and giving the compiler a chance to check the proper usage.

How do our interface Closure looks like with a generic touch?

public interface Closure<R,A> {
    public R exec( A arg );
}

as you can see, we define two generic types. one for the return type (R) and a second for the type of the argument (A). now this is still straightforward.

whats about our supporting classes? they now have the chance to define, which type of closures they will accept.
in order to make things more interesting, we will now extend the example and introduce a class CollectionUtils, which offers a couple of collection related functions, like filtering, converting or applying some processing to all elements of a collection:

public class CollectionUtils {

    public static <T> Collection<T> filter( Collection<T> source, Closure<Boolean,T> filter ){
         Collection<T> filteredElements = new ArrayList<T>();

         for( T item : source ){
             if( filter.exec( item ) ){
                filteredElements.add( item );
            }
        }
        return filteredElements;
    }

    public static <T,S> Collection<T> convert( Collection<S> source, Closure<T,S> converter ){
         Collection<T> convertedElements = new ArrayList<T>();

         for( S item : source ){
            convertedElements.add( converter.exec( item ) );
        }
        return convertedElements;
    }

    public static <T> void each( Collection<T> source, Closure<?,T> visitor ){

        for( T item : source ){
            visitor.exec( item );
        }
    }
}
 

lets take a closer look at the individual methods.
the filter() method will create a new collection for the books to filter which it will return after processing the source collection. the type of the filtered elements in this collection is of the same type of the elements in the source collection. it’s also the type of the argument, which the closure have to provide. further on, we demand from our closure to return an instance of type Boolean.
what do we have achieved?
first of all, we can use closures in a typesafe way, independent of any concrete type. regardless of filtering books, reports or shop items, you only have to provide a proper closure with the adequate type parameters. let’s look on how to filter books with our new closure:

public class CollectionUtilsTest {

    private Collection<Book> books;

    @Before
    public void setUpBooks(){
         books = Arrays.asList(
            new Book[]{
                new Book( "A Simple One", "Cole", 29.99f ),
                new Book( "New and fresh", "Simmons", 59.99f ),
                new Book( "The Big One", "Cole", 19.99f ),
                new Book( "Foos and Bars", "Adams", 24.99f ),
                new Book( "The Answer", "Iverson", 24.99f ) } );
    }

    @Test
    public void testFiltering() throws Exception{

        Collection<Book> filtered =
            CollectionUtils.filter( books , new Closure<Boolean, Book>(){
                public Boolean exec(Book book) {
                    return book.author.equals( "Cole" ); } } );

        assertEquals( 2, filtered.size() );
    }
}
 

as you can see, we’ve achieved even more: By instantiating a closure with the appropriate type parameters, there is no need to cast the argument. we can directly refer to the correct argument type Book.
(just as well we do not have to cast to Boolean in the method filter() , since it demands a return type Boolean from our closure). now the compiler is also able to check against the correct type parameters, so we have type safety at compile time.

our next method convert() is written in the same manner. this time we allow the closure to determine his return type by himself as he is responsible for the type of the converted elements. thereby the closure also determines the type of the returned collection for the converted elements of the method convert(). further on we link the type of the closure’s argument to the corresponding type of the elements of the source collection, so we are typesafe when we pass the elements to the closure. let’s look at the example, where we want to extract the titles of the books:

@Test
public void testConversion() throws Exception{

    Collection<String> titles =
        CollectionUtils.convert( books , new Closure<String, Book>(){
            public String exec(Book book) {
                return book.title; } } );

    assertEquals( 5, titles.size() );
    assertTrue( titles.contains( "A Simple One" ) );     assertTrue( titles.contains( "New and fresh" ) );     assertTrue( titles.contains( "The Big One" ) );     assertTrue( titles.contains( "Foos and Bars" ) );     assertTrue( titles.contains( "The Answer" ) ); }    

our last method each() offers no spectacular new insights. the only thing to mention is the fact, that it does’nt depend on any return type of the closure. therefore the method does’nt mind about it and express this freely.

summary

as we have seen, generics offer a new dimension to define typesafe closure-like constructs in java without the need of cumbersome and code blowing typecasts.
of course we can’t obtain the same power as with true closures in languages with built-in support for functional programming. but used in moderate doses, there is potential to improve the expressiveness of our code markedly!