Closures and Java: The Horror Story Begins

Previously I posted how it is too late for Java to include closures and it seems my fears have duly been confirmed. In a post on his blog Neal Gafter has already confirmed what we all knew already: that existing APIs won't be able to be changed to accomodate closures.

This is exactly what I said in my my previous post would be the critical problem with the closure proposal. So what do we get instead if existing APIs can't be changed? This is where it starts to become terrifying. Yes ladies and gentlemen we get the methods added to Collections accessible for a static import. I mean since when did Java become a functional programming language?

Neal presents the example as follows with the initial Java code being:

Droid seekDroid(Map map) {
    for (Map.Entry entry : map.entrySet()) {
        String droidName = entry.getKey();
        Droid droid = entry.getValue();
        if (droid.isSought()) {
            System.out.printf("'%s' is the droid we seek.%n", 
                              droidName);
            return droid;
        }
    }
}

This is fairly standard stuff made slightly better by the Java 5 for loop. Now to "optimize" this with the proposed closures we have the introduction of a new keyword specifically for looping in the for keyword:

Droid seekDroid(Map map) {
    for eachEntry(String droidName, Droid droid : map) {
        if (droid.isSought()) {
            System.out.printf("'%s' is the droid we seek.%n", 
                               droidName);
            return droid;
        }
    }
}

I mean how is this this better? There is hardly any difference in terms of LOC or code verbosity to the previous example. Not only that whoever thought closures were specially for looping has clearly lost the point. If you have to modify the language specifically to support one use case of closures that should be big ugly red flag waving.


Clearly supporting backwards compatability is going to be a huge stumbling block here and I fear what we will end up with is a botch job. Now just for comparison sake contrast the above example to the equivalent Groovy code:

def seekDroid ( map ) {
  def droid = map.find { droid -> droid.value?.isSought () }
  if (droid)
     printf ( "'%s' is the droid we seek.%n", 
               droid.value.name )
  return droid
}

Enough said really. Languages like Groovy and Ruby have closures at their core and they are not bolted on as an after thought. If closures are not embraced this way they will become more of an additional burden for the programmer to learn than something core to the language.

Needless to say the horror story doesn't end here, however, as let's take a look at the method that provides this feature:

public interface Block2 {
    void invoke(K k, V v) throws E;
}
public static 
void for eachEntry(Map map, Block2 block) throws E {
    for (Map.Entry entry : map.entrySet()) {
        block.invoke(entry.getKey(), entry.getValue());
    }
}

What can I say? That's about as clear as mud. Generics are bad enough as it is, but that is about as readable as a newspaper delivered in the rain. Implementing this method in Groovy would go something like this:

static eachEntry(Map map, Closure closure) {
     for(entry in map.entrySet()) {
         closure.call(entry.key, entry.value)
     }
}   

In my opinion, Sun need to carefully consider what they are doing here and whether it will cause more harm than good. It would be of more value for them to embrace dynamc languages like Ruby (which they are doing with JRuby) and Groovy than to bolt on something that has the bad smell about it that the current proposal does. They should be focusing on more important issues to Java such as decent desktop integration with Swing (which still fails to look and behave natively), shared VM on windows and other such well documented problems that never seem to get solved.

My 2c.