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.