CICE is a proposal by Doug Lea, Josh Bloch and ‘Crazy’ Bob Lee. It is being touted as a “closures” proposal for Java 7 alongside Neal Gafter’s BGGA (for instance). Here are some thoughts I had after reading their document:

So basically, CICE is syntactic sugar for anonymous classes. In Guice parlance, the following:

bind(Service.class).toProvider(new Provider<Service>() {

    public Service get() {

        return new ServiceImpl(); 

    } 

}); 

…becomes: 

bind(Service.class).toProvider(Provider<Service>()

                   { return new ServiceImpl; }); 

Scheme is one of my favorite languages. Scheme basically invented closures, so given this–what are my reactions to CICE?

First, this is what I call a closure: A block of statements which retains its lexical context indefinitely. A closure is also a first-class citizen, in that it can be stored in a variable and passed around like an object .

In CICE, you don’t implictly close over the wrapping lexical context

Uh, sure but what does that mean? It means local variables are not part of the closure’s immediate scope. Even though the appear to be:

public Runnable get() {

    int x = 1;

    Runnable r = Runnable() { System.out.println(x); };

    x = 2;

    return r; 

} 

… won’t work. r only sees x = 1. Local variables are actually copied to the block. By hiding the final keyword it fools you into believing this is not the case. The fix for this is to declare x as public:

public Runnable get() {

    public int x = 1; //huh?

    Runnable r = Runnable()

             { System.out.println(x); };

    x = 2;

    return r;

} 

I thought closures are supposed to prevent such malarkey, not induce it =P

Note: The BGGA proposal also added something like this not long ago, but it was an optionaldocumenting annotation @Shared, rather than a language construct (i.e. public keyword).

 Statement blocks are not anonymous

Blocks in almost every language thus far are anonymous (Ruby, Groovy, Python, etc.). A block in CICE is just a contraction of an instance creation step, so you still need to specify its type. The following (anonymous method) is not possible:

list.each({ it -> doStuffTo(it); });

Statement blocks are too type-restrictive 

By the same token, statement blocks are restricted to pre-existing types (i.e. single-method interfaces being subclassed). One powerful feature of closures in Scheme (and other dynamic languages) is they are type-neutral at the point of definition. This may seem cribby to you but:

(define add (lambda (x y) (+ x y)))

…can add two integers, longs, or floats. The function in add is type-neutral. This is *not* to be confused with duck-typing (Scheme is not duck-typed). There is a subtle point here that all functions in Scheme are type-neutral until they execute, but this is not what I am getting at (ignore that Scheme is dynamically typed for the moment). I concede that it is harder to type-check inferred-type methods in a statically-typed language like Java, but CICE makes this impossible without pre-defined generic types:

public interface Adder<N> {

    N add(N x, N y); 

}

I must declare this type simply in order to use it anonymously. This feels backwards to me. By contrast, this is a Haskell function:

add x y = x + y

Does add() take Ints? Longs? Floats? We don’t know until it is used. And we don’t care. Haskell functions are quantified over all types. In other words, they are type-polymorphic. Haskell is statically-typed, so this is not an apples-to-oranges comparison either (if you were wondering that it was with Scheme and CICE). The CICE proposal claims this is something that could be improved upon.

More on type-neutrality

OK, so you sort of grok that a closure is different from a CICE in that you don’t subclass a pre-defined type. But what’s so bad about that? One-method types are easy to create (and most useful ones already exist–example Callable<T> and Future<T>). Without resorting to duck-typing what else could I possibly think type-neutrality provides? “Real” closures possess function types. This essentially boils down to a tuple consisting of [R, A...An] where R is a return type and A…An are argument types. 

So what? Well–this actually means closures are quantifiable over all types matching the tuple (ANY matching function) and not simply a named type. Consider:

public java.lang.Runnable get() {

    return my.domain.Runnable()

        { System.out.println("Hi"); };  //error

}

As opposed to a real closure:

package some.other.domain;

...

public { => void } get(boolean where) {

    return where ? { => System.out.println("Hi"); }

                 : my.domain.Closures.bye() ;

}

Named types don’t enter into it. The closure’s type is captured over its functional type signature, which effectively gives it the flexibility of structure typing (but without contaminating the structuraltype system itself–unlike scala). Much more powerful indeed.

Other stuff

•  this keyword refers to the inner type and must be qualified to refer to the enclosing scope
•  Return types must be specific to the type being subclassed in the CICE. You can’t simply return a value from a block of code.
• Same with checked exceptions thrown (there are workarounds with generic throws clauses)
• Block-arguments also must match the signature of the interface type. Covariant argument typing is not possible (again messy workarounds are possible with generics)

For these reasons I believe it is misleading to call CICE a “closures proposal”.  It should certainly not be considered in the same vein as BGGA for instance. Note that none of this speaks to the merits of CICE as a code footprint reduction proposal. Nor to BGGA in terms of its merit as a closures proposal. 

I am not endorsing either proposal, nor condemning CICE as a language feature. I just want to highlight that it is inaccurate to equate CICEs to closures.

Email me your thoughts.