Limitations of Java Anonymous Classes compared to Objective-C Blocks

Question

I'm just starting to wrap my head around first order functions and closures after discovering blocks in Objective-C. Java is another language where I've heard about closures (or lack thereof) and how anonymous classes make up for this somewhat.

I can definitely see the advantages of closures as blocks in Objective-C, but what are the limitations of anonymous Java classes? To what extent do they 'somewhat' make up for the lack of true closures?

Answer 1

Java anonymous classes are really, really wordy. Apart from the vast amounts of boilerplate that you need just to define them, some of Java's design decisions mean that a lot of common tasks are much more verbose than in other languages. For example, importing mutable upvalues into the closure is a pain in the arse in Java.

Basically, Java doesn't support upvalues; instead they're simulated by passing them (by value) into the class via invisible parameters to the class's constructor. Because they're passed by value, modifying them inside the class won't affect the copy in the method that constructed the class, so the compiler makes you declare them final to avoid confusing yourself. e.g.:

Runnable function()
{
   final int i = 4;
   return new Runnable()
   {
       public void run()
       {
            System.out.println("i="+i);
            // can't modify i here
       }
   }
}

On occasions where you do need to modify the variable, for example in pretty much every case where closures would be useful, you have to cheat:

Runnable function()
{
   final int[] i = new int[1];
   i[0] = 4;
   return new Runnable()
   {
       public void run()
       {
            System.out.println("i="+i[0]);
            i[0] = i[0] + 1;
       }
   }
}

Here, i itself is still immutable, but because it points at a mutable object, I can change the contents of the object. (Naturally, in real life I'd use a class rather than an array, because using arrays is really ugly. And that makes it even more wordy.)

I gather that the next Java release is going to have syntactic sugar to make all this easier, but right now closure-centric programming is pretty cumbersome in Java. I find it's frequently easier to change the logic not to use closures, simply to allow me to keep the amount of code in use small enough to be comprehensible.

Answer 2

I don't really know about the objective-C version of closures, but I know them from Smalltalk and Lua.

A closure is essentially a function which has access to a local variable of some other function/block (usually one in which the closure is syntactically nested). This way, the local variable can live longer than the block it is defined in. When you have multiple closures over the same variable, they can communicate using this variable.

Java's local classes (of which anonymous classes are a special case) support a limited version of this: They allow access to a final variable, i.e. a variable which can't change it's value. This is implemented by copying the value of this variable to the local class object on it's construction. You can emulate real closures by using a mutable object in this variable (in the simplest case a one-element array).

Additionally, the Java syntax for this is quite ugly, but it fits in with the rest of the language nicely, and allows static type safety (contrary to some shorter-syntax variants which are discussed).