I started out nervous with the idea of adding closures to Java, and I think I’ve slid firmly into the “contra” camp. One reason is that it seems increasingly a bad idea to add anything to the Java language. On a related subject, my brief sojourn in Ruby-land has changed my thinking about closures entirely.

Java and Closures · A good place to start is Bharath’s BGGA closures: The end of many Java careers. Clearly he’s a contra too, but he links to both sides’ arguments.

My argument is simple: Java worked so well because it hit the 80/20 point; for my money one of the loudest, cleanest 80/20 technology victories ever. Subsequent attempts to fill in the 20% were, well, mostly harmless. Until generics, which are a disaster; they have made Java harder to learn and to understand, and you can’t avoid them.

So I’m really scared about trying to chip away any further at whatever’s left of the 20%. Also, I look at the motivating examples for closures and I think that the conventional alternatives aren’t that bad. Also, I look at the proposed code and I think that on balance it’ll make Java harder to read. Also, as Bharath points out, if you really need closures and and functional-programming goo and suchlike, there are at least two excellent Java-platform languages that have elegant, well-tested designs: Scala and JRuby.

But you know, I could be wrong. Maybe there’s a way to build closures into the Java language in a way that’ll add power smoothly with no real downside. If that’s true, we need to discover it and prove it, and the JCP isn’t about discovering things; it’s about the worst possible place to approach this problem. Now that Java is Open-Source, anyone can go cook up whatever loony closure facility they want, and if it’s good enough, people will start using it whether the binary build has “Java” stamped on the outside or not, and then start shouting that it should be in the standard distro, and only then should the JCP consider going near this tar-pit.

My favorite place to start improving Java wouldn’t be with the language at all, it’d be the Multi-Language VM project. The motivating use-cases for that aren’t theoretical in the slightest, they have names and addresses and are screaming for love.

Ruby and Closures · Ruby calls ’em “blocks” and you basically can’t write any code without ’em. When you first see how they’re used, you think “Hey, that’s a nice clean way to do iteration”. Then when you want to write one of those functions, you dig in and find out about yield , and you nod your head “of course”.

They have to be closures because they look like (and are) chunks of code embedded in your classes and methods, which can naturally use those classes’ and methods’ variables. So there’s nothing in the slightest strange or surprising.

Later on, when you get a little deeper into Ruby, you find out about &block arguments and procs and lambdas, but by that time you’ve internalized the notion that a few lines of code have an independent life even if they don’t have a name, so the mental effort in figuring it all out is about zero.

But even in Ruby, to my eyes the most readable of languages, code that uses procs and lambdas is often hard to read. (Code that uses ordinary blocks is trivial to read, the closure-ness is implicit and invisible).

And at the end of the day, the number of times an application programmer is going to really need a proc or a lambda, to the extent that it’s a win to suck up the readability cost, probably isn’t that high. Yes, it happens; I’ve done it myself. But as I said, not often.

Conclusion · Sorry, I don’t have one. Ruby proves that it’s possible to get closures right and make them accessible to grunt programmers. But if they’re going into Java, they need to earn their way and be field-tested in the open-source ecosystem first.