Introducing true closures into Java has been the subject of heated debate lately. The latest contribution to this discussion is a proposal by Josh Bloch, Doug Lea, and Bob Lee, Concise Instance Creation Expressions: Closures without Complexity. The pair notes that:

Since release 1.1, Java has had closures in the form of anonymous class instance creation expressions ... that extend a class or interface with a single abstract method. We call such classes and interfaces single-abstract-method types, or SAM types for short... The resulting closures are often used to parameterize the behavior of collections (e.g., a Comparator specifies the order of a SortedSet), and to submit code for concurrent execution (e.g., a Runnable may be executed by a Thread or an Executor). Unfortunately, the verbose and ungainly syntax of anonymous class instance creation expressions frustrates programmers...

They propose to make working with SAMs easier:

The basic idea is to omit the keyword new, the class declaration, and the method name from class instance creation expressions... For example, here is the Java 5 code to start a thread whose run method invokes a method named foo:

 
new Thread(new Runnable() {
    public void run() {
        foo();
    }
}).start();

If we adopt this proposal, the following code would be equivalent:

new Thread(Runnable(){ foo(); }).start();

Bloch and Lea term the proposed construct "concise instance creation expression" (CICE), noting that "you can use a concise instance creation expression everywhere that an instance creation expression is currently legal."

Bloch and Lea's proposal also addresses the oft-mentioned developer gripe of having to declare final any variable accessed form an anonymous inner class:

We propose making such variables final by default. Programmers also complain that instance creation expression method bodies are not permitted to share mutable local variables with the enclosing scope. Therefore, we further propose allowing such access if the local variables in question are explicitly declared public.

Here's an example of the "annoying final" in Java 5. This method takes a comparator and returns a comparator that induces the reverse ordering:

static  Comparator reverseOrder(final Comparator cmp) {
    return new Comparator() {
         public int compare(T t1, T t2) {
            return cmp.compare(t2, t1);
         }
    };
}

Here's how the method would look if this proposal were adopted:

static  Comparator reverseOrder(Comparator cmp) {
    return Comparator(T t1, T t2){ return cmp.compare(t2, t1); };
}

Of all the recent proposals to add true closure support to Java, Block and Lea's sounds rather reasonable, because it would actually simplify current syntax by making a set of assumptions based on current practice.

What do you think of the Bloch and Lea's proposal?

bar.action += foo.action;

Thread foo

ls->SortBy Size

ls->Sort ?s1 s2 {Size s1 < Size s2}

// declaration
class SomeCollection implements java.util.Collection {
   // ....
 
   /** method with method parameter */
   Collection filter(boolean includeObject(Object o)) {
     Collection retval = new SomeCollection();
     for (Object o: this) {
       // use closure method passed in
       if (includeObject(o)) {
           retval.add(o);
       }
     }
     return retval;
   }    
}
 
class User {
  
  private boolean isJohnDoe(Object o) {
     return ((User)o).getName().equals("John Doe");
  }
 
  public static void main(String[] args) {
     SomeCollection sc = new SomeCollection();
     // ...
 
     // invoke by naming method to transfer as closure
     // no parameters to the closure method here, 
     // since it is not invoked _here_ but in the 
     // receiving method. 
     Collection johnDoes = sc.filter(isJohnDoe);
  }
}

bar.action += function(int x){ return bar.x + x; }