Adding closures to the Java language is at the center of the debate concerning Java's future: Some believe that closures are such an important construct, supported by many other modern languages, that Java's lack of closures support would sooner or later entice developers to replace Java some other language as the workhorse language in their tool box. Others argue that adding closures would make Java even more complex, harder to learn, and that such added complexity may turn developers away from Java.

Advocates of these opposing views have produced several proposals to add closures-like syntax to Java. In a recent JavaWorld article, Understanding the closures debate, Klaus Kreft and Angelika Langer dissect the three major closures proposals from the viewpoints of complexity and expressiveness:

Closures [are] a standard feature in older languages such as Scheme, Smalltalk, and Lisp, and have more recently made their way into dynamic languages such as Ruby and Groovy. Closures are a natural fit for statically typed, functional Scala, and recently many have argued that they have a place in the Java language, too...

Many developers argue, conversely, that closures are a bad fit for the Java language. According to this camp, adding closures would be the proverbial "nail in coffin" for the already stuffed syntax of a language that tries to do too much...

The BGGA proposal started the "closures in Java" discussion... BGGA adds a lot of power to the Java language, but also a lot of complexity.

CICE stands for "Concise Instance Creation Expression," [and] is considerably less complex than BGGA and advocates an approach that is best described by its tagline: closures without complexity. In CICE, closures are essentially an alternative syntax for inner classes. CICE closures stick close to the existing Java language and do not add much new functionality...

FCM stands for First Class Methods ... is somewhere between CICE and BGGA, and is much closer to BGGA. It mainly differs from the other two proposals in how it introduces closures into the Java language: not as an isolated novel concept, but embedded into an approach that allows handling of types and references of methods as first-class elements in Java. In FCM, a closure is just a special kind of method: the inner method...

In the article Kreft and Langer summarize key points of the closures debate:

One thing all of the closures proposals agree [on] is the need to conceptually replace inner classes with a more powerful programming construct. Adding closures to the Java syntax would not mean losing inner classes; rather, the two constructs would be compatible and interchangeable. The advantage of closures, of course, is that they add flexibility and power not found in inner classes...

There is one area where the proposals differ drastically. In the BGGA proposal it is permissible for a closure to contain non-local control statements that affect the control flow of the context in which the closure is defined, not only the control flow within the closure itself... The introduction of non-local control statements distinguishes BGGA from the CICE and FCM proposals...

What's your take on the various Java closures proposals?

public class Text implements Block<integer>
 
    public static void main(String[] args) {
        List<Integer> nums = Arrays.asList(1,2,3);        
        Utils.forEach(nums, new Text());
      }
    
    public void invoke(Integer t) { System.out.println(t); }
}

Invoke<IN, OUT>   (much like in the article) {
   OUT invoke(IN in);
}
 
 
FPMap<KIN, VIN, KOUT, VOUT> {
   Collection<Map.Entry<KOUT,VOUT>> map(KIN inKey, VIN inValue);
}
 
 
Reduce<IN, OUT> {
  OUT reduce(Iterable<IN> inList);
}