Closures — Really, no thanks

After reading the excellent article Java: Evolutionary Dead End by Bruce Eckel and looking through Joshua Bloch’s presentation Closures controversy, I’ve become convinced that I really, really don’t want closures in Java.

I agree with Bloch that you can’t look at the complexity of a language feature in isolation. You have to consider it together with all the other features of the language. That means every new feature brings a nontrivial increase in complexity.

…that it’s not just the complexity of a particular feature in isolation, where it can often seem fairly straightforward. It’s the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. When you shoehorn a feature into an existing language rather than carefully designing it in from the beginning, you cannot control how that feature combines with other existing features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it’s too late to do anything about it.

Generics, added in Java 1.5, are a fine illustration of that point. Let me quote from BGGA closures: The end of many Java careers.

It would be a mistake to evaluate the complexity of BGGA in isolation. Indeed, the 427 page generics FAQ, for instance, doesn’t talk about generics in isolation. In reality, it is the interaction of generics with other language features that makes generics so hard to master. Its a curious coincidence that Angelika Langer on the generics FAQ thanks 3 of the 4 BGGA authors for patiently answering “countless questions posed” regarding generics. You’d expect that the BGGA authors’ first initiative would be to simplify generics and make its behavior & interaction with other language features more predictable, instead of attempting to make changes that further convolute the type system and add cognitive load to the language for little benefit.

It’s worth asking what’s behind the push to add closures to Java. Eckel offers an interesting parallel with generics.

This was remarkably coincidental with the appearance of generics in C#, which also appeared to produce several other features in Java 5. It seems that the urgency of these features came not from solving true problems in the Java language, but in Sun trying to maintain the perception of competitiveness against Microsoft’s C#. This is probably not so far off the mark, because the reason that Java had to be rushed out in rough form in the first place was the belief that there was a market window that must be captured. A programming language designed by following marketing impulses is eventually going to end up chasing its tail.

In my view, the BGGA closures proposal (BGGA takes its letters from the surnames of the proposal’s authors, Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé) offers almost no benefit compared with the problems it will create.

My problems with closures:

• More complicated syntax, leading to code that’s harder to read and maintain
• Uncertain complexity from interactions with other language features
• A backward-incompatible change
• Unclear motivation. Who benefits?

The attempt to make Java a multipurpose language, which is what the closure proposal looks like to me, will ultimately work against the Java language itself. After taking features from functional languages, we’ll start adding syntax from languages designed for concurrent processing, such as Erlang. Java’s infrastructure, the JVM, gives us enough options to handle particular requirements with languages designed around them.

In his presentation, Bloch offers a simpler form of closures. I’d call his proposal a little syntactic sugar. For me, that’s about as far as I can go in good faith as an alternative to anonymous inner classes.

Earlier related articles

• (Dagblog 5.9.2006)Closures in Java — Functions revolt
• (Java drobečky)Closures in Java — No thanks