Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

Closur-izing Java 7 Libraries is Important for Closures

  • submit to reddit
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.
Article Resources: 


Ronald Miura replied on Tue, 2010/05/18 - 7:40am

Wouldn't it look too much like multiple inheritance (with all the problems it brings)?

Brian Goetz replied on Wed, 2010/05/19 - 10:06am

Where did you get the idea that library evolution must happen *before* closures? No one at Oracle has suggested any such thing. Instead, closures and library evolution are synergistic, so it makes sense to explore them together rather than treating them as completely separate issues.

Mitch Pronschinske replied on Thu, 2010/05/20 - 11:36pm in response to: Brian Goetz

Good point.  I misread your intentions.  Some of the language of this post has been updated.

Brian Goetz replied on Tue, 2010/07/06 - 11:26am

There's a substantially updated version of the document that replaces this one. Can you update your cached copy?

Mitch Pronschinske replied on Fri, 2010/07/09 - 1:25pm in response to: Brian Goetz

Replaced it just now with the second draft.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.