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.

JSR-305

This Google Tech Talk was about JSR-305, a JSR that was adopted and will be in Java 7 (I believe). This JSR involves added annotations for software defect detection - essentially, it aims to provide standard annotations that tools can understand and use to help detect errors in your code. Some of these have been implemented nonstandardly in tools such as IntelliJ, such as the @Nonnull annotation.

This talk went over what would be provided and examples of why this would be useful, instead of going into implementation which would be tool-dependent. He did mention one possibility for enforcing these annotations at runtime, but I think it would have been interesting to go more in-depth on this. Oh well, there’s only so much you can cover in an hour.

I’ve known about some of the annotations before as ones that were coming to Java7, eg @Nonnull, but not some of the others. While (hopefully) the ones built-in to Java7 will have compiler support, since the JSR includes a way of defining your own classes it would be nice if there was a way to be able to tell javac how to verify those, reducing the need for external tools. On second thought, this seems like informing the compiler how to check for violations of these annotations seem rather difficult; maybe it should be left to tools developers.

One thing mentioned in this presentation that I was unaware of was class- and package-level default annotations. When I heard about @Nonnull, I liked the idea, but it seemed like it would end up making Java even more verbose, since you’d usually want to add it to essentially every variable. Default annotations allow you to annotate a class or package and essentially have variables ‘inherit’ from this default; this allows you to make every variable in one class @Nonnull with only one annotation, much better than if each variable declaration needed an annotation.