Closur-izing Java 7 Libraries is Important for Closures

DZone 's Guide to

Closur-izing Java 7 Libraries is Important for Closures

· Java Zone ·
Free Resource
It's no secret that some developers in the Java community are doubting whether or not closures in Java 7 will be ready by the deadline this year.  Over the weekend, Brian Goetz, a Senior Engineer at Oracle working on Java 7, posted a document suggesting that some work be done on Java's aging Collection interfaces in order to update the appropriate Java libraries in addition to implementing closures.  Goetz believes that adding closures without extending Collections classes to better harness closures with methods like filter, reduce, forEach, etc. "would be seen as anticlimactic by the community."  Goetz has therefore published a preliminary proposal-like document for public defender methods (aka virtual extension methods)

Goetz explains: "Adding closures to the language without closure-izing the libraries will be unsatisfying for the users.  Without a means of interface evolution, we cannot closure-ize the libraries.  We explored static extension  methods, but they are pretty unsatisfying; it is impossible for an  implementation to provide a better implementation.  If its true that "today's  problems come from yesterday's solutions", static extension methods feel to me  like tomorrow's yesterday's problematic solution (parse that if you can!)"

With virtual extension methods, Goetz says existing interfaces could be added onto without compromising backward compatibility.  Here is a purely illustrative example of how a virtual extension method might look:
public interface Set<T> extends Collection<T> {
public int size();
// The rest of the existing Set methods

extension T reduce(Reducer<T> r)
default Collections.<T>setReducer;
Read the document for a fuller explanation of the defender methods, their implementation, and their possible effects on the language.  

Neal Gafter, a strong advocate for closures in Java, saw two separate language proposals in Goetz's document:  

"The first is the ability to put default method implementations into an interface.  The second is the ability to provide a method implementation by reference to another method.  It isn't clear why one would intertwine the two proposals, and I don't understand the motivation for the latter (I don't buy the conclusion in the "Syntax Options" section).  I'm guessing it is in part to simplify the implementation strategy, but that is a poor motivation…

My most important comment is this: the relationship between this proposal and the (not well described) goals of project lambda are not clear.  What software engineering techniques are you trying to enable, and for whom, and how does this proposal improve things?  Without a clear explanation, this is a solution in search of a problem."  -- Neal Gafter

Stephen Colebourne, a Java Software Architect, also had some criticisms about the difficulties in being a meaningful participant in some of the discussions and processes:

"I perfectly well understand that Oracle has met, discussed and decided to reject other options. The problem is that you've not done it /publicly/. As such, those of us outside Oracle are left with guessing at what thought processes you went through and reasoning you had. This makes it nigh on impossible to provide the meaningful feedback you'd like, or for you to win the trust of the broader community." -- Stephen Colebourne

However, Colebourne did say that he liked the direction of the document and gave a good amount of feedback.

Goetz says another possibility would be to add closures first and add the library changes in a future update or SE8.  Goetz has now posted a document describing a "somewhat naive" translation strategy for the translation of lambda expressions by javac here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}