cheers, Ride
.

Sensible defaults and compiler interpretations are one thing but powerful abstractions and actual closures are another.

Full closures would provide Java with a more complete and extensible solution. They would solve all the common problems already mentioned and allow developers to solve even more. A lot more! A compiler/parser solution would be too limiting for developers and would not add any value to the API. Full closures would add a lot of value.

The closure syntax is what really concerns me though.

Anonymous class instance creation can be done just fine by making the compiler smart about interpreting what you write.

Taking the classic comparison example, observe the following chain:
Collections.sort( list , new Comparator() { public int compare(Integer a,Integer b) { return a-b; } } );
// There’s only one method, use an easier way to pick it out:
Collections.sort( list , new int Comparator.compare(Integer a,Integer b) { return a-b; } );
// The interface requires type matching of arguments, so
Collections.sort( list , new int Comparator.compare(a,b) { return a-b; } );
// Sort requires a type-matched comparator
Collections.sort( list , new int compare(a,b) { return a-b; } );
// compare is the only method not in Object
Collections.sort( list , new int ?(a,b) { return a-b; } );
// We obviously want a new thing that returns a value
Collections.sort( list , int ?(a,b) { a-b } );

You don’t need first-class methods or anything. The last is more compact than anything suggested by closures, is completely unambiguous, and is a simple matter of making the parser understand sensible defaults. If there is no sensible default, it’s a compile-time error.

If anything, closures would get in the way of allowing sensible-defaulting to reduce all the redundantly unnecessary code one has to write at the moment.

ARM can be done just like foreach iterators are done now:

interface Resource
{
void acquireResource();
void releaseResource();
}

(You could do this fine without generics also.)

Now, anything that has resources implements the interface, and we interpret:

try ( my_object ) { . . . }

as

my_object.acquireResource();
try { . . . }
finally { my_object.releaseResource(); }

No perplexing return-does-different-things needed like in BGGA; it just works, and in the manner of foreach.

Speaking of foreach, closures let you cover every case (with questionable clarity), but what are the common cases?

Dual iteration has a natural extension:
for (String s : stringlist ; double d : numberlist)
{ System.out.println(s + ” has value ” + d); }

Subdivision of complex iterators have a natural extension:
for (String s,double d : hashmap)
{ System.out.println(“Key ” + s + ” has value ” + d); }
where this is specifically smart enough to understand key,value pairs.

Anyway, making the language require a lot less unnecessarily repetitive typing doesn’t require closures at all. There are other solutions that fit better with the language structure and which solve the problems better.

Closures/lambda functions can be useful if you don’t have inner classes, or if you don’t have robust types. I can’t see how Java benefits from them in any interesting way.

Some treat this as bad because badly trained monkeys might produce unintelligible code.

I say that’s what policy, code review, training and hiring good people is about – people are abusing the features of the language already but I’m glad we have the features we do when we need them… I’d have a couple of good uses for closures day #1 and they’ll all simplify code.