If you say that you don't like closures you immediately get this in return: "That is because you don't understand how good they are. Look at language xxxx to see how useful they are and how many keystrokes you save and what cool things you can do that you can't do with Java" . This has been a major pain when arguing against closures i Java since I always end up on the defensive side explaining that it would be good for some, but not for most, and the people it wouldn't be good for is not actually me. Confusing? Yes. Read on.

What Problems do Closures Solve?

When changing something there's a cost. For instance everyone have to relearn it and that costs resources. The benefits must be proven to be measurably greater than the costs or we are doing it just because it's cool or plays well with our ego.

The benefits with closures are commonly answered with a code snippet of some cool thing you can do that is using less than half of the keystrokes that an anonymous inner class would typically take. This isn't interesting at all to me as I typically just use a couple of keystrokes to create the anonymous inner class. IDEA is filling in the blanks for me and Ctrl+Shift+Space counts as one keystroke in my book. I would guess that the more advanced coders, the ones that is usually on the closure side, does this as well, so the inverted keystroke battle is irrelevant IMO.

Then we have the aesthetics. Anonymous Inner Classes (AIC henceforth) aren't pretty, they actually looks like shit. Closures on the other hand, in their purest form at least, looks very good, almost sexy (to a developer . That is unless you have to use one of the proposed syntaxes for handling exceptions thrown in the closure or have some funky return structure. The solution to this aesthetics problem isn't closures though, it can be solved without adding complexity by just allowing a little syntactic sugar for the AICs. They can be done so much prettier (and with less keystrokes for those non-IDEA users) in simple ways and there are examples of this floating around the net.

Then there is the "Closures can do many things that AICs can't. Change the variables outside their scope for instance". I'm not sure this is such a great idea. I think it somewhat breaks the KISS principle and the "what you see is what you get" idea that Java is based upon. Bug fixing and support is in larger projects a greater cost than saved keystrokes and this would lead to new types of hard to understand bugs. I know you can do really fancy stuff but on the other hand I haven't really felt the need for this yet and I have been writing code for a long time. Sure, it's another tool in the toolbox, but a tool that is looking for a usage rather than the other way around. If needed we could drop the requirement for the "final" variable declaration but I still think that the AIC should only be working on a copy of the value. The final is not the ultimate bug defending solution anyway since it just enforces the reference or primitive value and not the properties of that object.

Closures solve some problems and use-cases, but most of them have much simpler solutions that doesn't complicate things.

What is the Cost of Adding Closures?

There is a cost to everything. The primary cost here is that Java developers need to learn new constructs. Constructs that are not very Java-ish and therefore will take some time to getting used to. The concept of closures is more involved than AIC, and I know some are struggling with AICs... Remember that not all are as bright as you and you gain nothing from alienating the Java-Joes however good that feels for your ego. In fact there is a good chance you'll have quite a few Java-Joes in your team, since average is average and half of the developers is below average (I know, the median really).

Sun has made it clear that they need to make Java easier for the newbies to reach its goal of ten million Java developers. In fact simplicity has been a major theme for quite some time now. Java stands for KISS regarding the language and it is really the APIs such as JEE and Swing that are targeted by Sun in this matter. Closures goes the other way. It makes the Java language harder to grasp. So Sun is making the APIs easier to use but are suggesting that the language itself should trade simplicity for power. Not very consistent.

Carrying the Legacy

You favorite "other" language probably has closures. I have nothing against that. Those languages were created with closures in mind and when you learned them closures was in the APIs. With Java the problem is that the APIs weren't created with closures in mind and they aren't supported without jumping through hoops. Take the much loved Collection framework. If it'd been closure-enabled from day one it would've been even better. Now you need to squeeze in closures either by creating a new, alternate, Collections framework with closure syntax support or by using other more "fancy" wrapping constructs. Bottom line: Buying G-Strings for your middle age wife doesn't make her look 18 again. Sorry.

Conclusion

I think that closures are the rocket scientist's answer to a problem that can be solved by a plumber and a carpenter. If closures would have been here from the beginning I would have loved it but that is not the case and there's nothing we can do about that now. C++ went down the power over simplicity road and never came back. Closures is the Pimp My Ride answer to more efficient car pooling.

Disclaimer

If closures gets added I will use them and like them. I will make cool constructs that saves keystrokes and I won't abuse them, which is possible (but that goes for just about anything). I'm probably not the average user though and when writing this I'm thinking about the prosperity of the Java platform not my personal satisfaction.

Cheers,
Mikael Grev

import static java.util.Collections.eachEntry;
 
  Map<String, Integer> map = ...
  eachEntry(String key, Integer value : map) {
    // do stuff with key and value
  }

import static com.google.GoogleUtils.performanceTime;
 
  performanceTime("gmailPerformanceLog.txt") {
    // code to be timed and logged for performance monitoring
  }

using(new PerformanceTimer("gmailPerformanceLog.txt")) {
  // code to be timed and logged for performance monitoring
}

import static java.util.Collections.eachEntry;
Map<String, Integer> map = ...
eachEntry(String key, Integer value : map) {
  // do stuff with key and value
}

import static my.funny.Utils.eachEntry;
 
Map<String, Integer> map = ...
eachEntry(map, new MapVisitor<String,Integer>() {
  public void visit(String key, Integer value) {
    // do stuff with key and value
  }
});

Map<String, Integer> map = ...
eachEntry(map, new MapVisitor<String, Integer>(String key, Integer value) {
    // do stuff with key and value
});

Map<String, Integer> map = ...
MyMapVisitor<String,Integer> visitor = new MyMapVisitor<String,Integer>();
eachEntry(map, visitor);
int sum = visitor.getSum();
 
// Implementation of the MapVisitor is left as an exercise to the reader ;) 

class HelloWorld {
    System.out.println("Hello World!");
}

each(String key, Integer value : map) {
    // do stuff
}

public static <K,E> void eachEntry({K,E=>void} block, Map<K,E> map) { ... }

eachEntry(map) {String key, Integer value => ... }