Musings of a Software Engineering Student

Advanced Topics in Programming Languages: Closures for Java

This Google Tech talk was quite interesting, although a bit depressing since it seems unlikely that Java will get closures anytime soon. Still, it was a great talk on how closures could be added to Java cleanly.

The talk starts off with describing use cases for closures. The two main issues were to enable control abstraction APIs and to make API calls easier. Enabling control abstraction APIs means allowing programmers to define abstractions like the foreach loop without having to wait for them to be added to Java itself. Making API calls easier by removing the reliance on anonymous inner classes (which closures get compiled to) also looks quite nice.

The talk first presents a way of defining foreach using anonymous inner classes, and shows the problems that occur with this approach. The first is an issue with toString and lexical scoping, and then goes on to the problems with Exceptions, return and break statements, being unable to access non-final variables, etc. Many of these problems have solutions, but solving these problems has nothing to do with what you are trying to express and solving them just obscures the business logic.

A few examples of where closures would be useful are then presented. The first was a withLock construct, though the concept also translates to streams. The accepted Project Coin proposal on automatic resource management implements a subset of what you would be able to do with closures, using them to automatically close streams. Another example is performing timing on functions - without closures, this adds at least 7 lines of non-business-logic code to each method you want timing information on, whereas you could program a withTiming closure and only take two lines.

The talk outlines the requirements than any proposal for adding closures to Java must implement. The first is that it must be able to create control abstractions that are on par with built-in statement forms. They must be concise, or there’s no advantage in using them. Lastly, they must inter-operate with existing APIs that currently take anonymous inner classes.

The details of the proposal, which were quite interesting, were then presented. This proposal adds function types to Java - for example int=>int represents a function that takes an int and returns an int. Function types are implemented as an interface generated on-demand with an ‘invoke’ method. Since they are regular interfaces, you can extend them, make them serializable, all of the things you can do with regular interfaces. The syntax for closures is:

     {int x => x + 1}

Which represents a closure that takes an int and returns it’s increment. Unfortunately, closures do not have any way to yield a result early - returns will return from the function the closure is in, not the closure itself. The way these closures are made to be inter-operable with existing APIs is through a process called ‘closure conversion’, which will make a closure auto-implement an interface such as runnable if the argument is a Runnable. The compiler is required to enforce this, so you can pass in closures to API calls requiring a Runnable and it will work as expected.

To simulate build-in control abstractions, such as withLock, you don’t want to have to pass in a closure as an argument. The proposal thus suggests that functions requiring a closure as the last argument can be expressed as

withLock( lock ) { doSomething(); };

instead of

withLock( lock, {=>doSomething();});

which is much less cumbersome.

These closures work properly - they can access local variables, throw exceptions, and are interoperable with existing APIs. You also have completion transparency, which is the ability to create functions which return the same type as a closure they take as an argument. This allows for constructs such as withLock to not need to worry about the return type of the closure; you can define one withLock function and then be able to return calls to withLock as the proper type.

The talk wraps up with a number of examples of how closures could be used, and then a link to where you could get more information on the proposal. This was a great talk, and I wish the proposal was going to be implemented in Java 7.

Tags: google tech talk, java

This entry was posted on Wednesday, September 23rd, 2009 at 11:39 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.