How will closures in Java enable API design to replace language design?

Question

I can see some of the benefits of closures, such as how they can have their place in simplifying existing libraries and making some future design easier and more efficient.

However, one of the key points mentioned in the draft proposal (http://www.javac.info/consensus-closures-jsr.html) is in section 2.5, point e:

(The specification will improve the language by)

e) enabling future API design to replace language design for extending the Java platform.

I'm struggling to see how this is the case, surely language design is just that - the design of the language itself, and can't be replaced by an API unless Java opens up all sorts of weird APIs using closures for modifying the language (which I highly doubt will happen.)

Can anyone shed some light on this and perhaps provide an example of something that required a language change previously but, with the addition of closures, no longer requires one?

Answer 1

API design and language features are definitely interchangeable at some points. Just look at something like the synchronized key word in Java. It's a keyword, but could just as well be implemented as an API if the language was sufficiently non-verbose. Annotations are another example. The other way around an @Stateless annotation that makes all methods in a class transactional, could also have been a language keyword.

Closures in particular make it easy to hand a "block of code" to a method, which could then do something with that.

A crude example, a for each could be made:

for_each(myFooList, #(Foo foo) { 
   String something = foo.getBar() + foo.getKaz();
   System.out.println(something);
});

Maybe not 100% as clean as having the for each loop directly supported by the syntax of the language, but it allows everyone to easily experience with language-like enhancements.