Closures for Java or money back

Joel Spolsky in Can Your Programming Language Do This? (Aug 1, 2006):

Java required you to create a whole object with a single method called a functor if you wanted to treat a function like a first class object. Combine that with the fact that many OO languages want you to create a whole file for each class, and it gets really klunky fast. If your programming language requires you to use functors, you're not getting all the benefits of a modern programming environment. See if you can get some of your money back.

Bracha, Gafter, Gosling, and Ahé in Closures for Java (Aug 18, 2006):

Modern programming languages provide a mixture of primitives for composing programs. C#, Javascript, Ruby, Scala, and Smalltalk (to name just a few) have direct language support for function types and inline function-valued expression, called closures. A proposal for closures is working its way through the C++ standards committees as well. Function types provide a natural way to express some kinds of abstraction that are currently quite awkward to express in Java. For programming in the small, closures allow one to abstract an algorithm over a piece of code; that is, they allow one to more easily extract the common parts of two almost-identical pieces of code. For programming in the large, closures support APIs that express an algorithm abstracted over some computational aspect of the algorithm. We propose to add function types and closures to Java. We anticipate that the additional expressiveness of the language will simplify the use of existing APIs and enable new kinds of APIs that are currently too awkward to express using the best current idiom: interfaces and anonymous classes.

Java needs real closures but no anonymous functions

Adding anonymous functions to Java isn't orthogonal, as we already have a unit of abstraction: the class. Of course the class isn't a great unit but having two distinct forms of abstraction is worse, IMO. With classes we can pack methods together, but if we use anonymous functions we must use separate names or refactor to introduce a class.

What Java really need is proper support for anonymous objects. At least we need type inference and structural subtyping, so we can write:

executor.execute(new {run() {System.out.println("Hello, world!");}});

and let the compiler figure out that the anonymous object given as a parameter to execute has a run method that conforms to the Runnable interface. The syntax could be nicer so we could drop a couple of brackets but it's the semantics that must be fixed, otherwise we are just adding syntatic sugar to an already bloated language, IMNSHO.