Yesterday (Dec 14) Alex Miller posted "Through the Java looking glass", which brought up some interesting points regarding the new Java 7 additions to the language wondering aloud if Java 7 "is going to succeed in creating an environment that still makes sense or whether it will be just the ugly step-child of these ideas which are better executed in their own environments".

http://tech.puredanger.com/2007/12/14/through-the-java-looking-glass

As you may know Alex hosts the best site that follows all the Java 7 developments in one place over at at http://tech.puredanger.com/java7 So I took notice when Alex questioned these new features and realized that perhaps many of us are blinded by the "me too" rush for these features in Java 7.

I recall when Gregor Kiczales (father of AOP) and company gave one of the first AOP sessions at JavaOne 2000 and have too wondered why AOP did not catch on with developers and why only now is prevalent in frameworks like Spring, Hibernate, etc. Likewise I presented an OSGi session at that same JavaOne 2000 and suggested using OSGi not just for home automation but as the basis for enterprise application development only to see it now be touted as a "new technology" by some and available in frameworks like Spring.

So will Java 7 closures (for example) follow a similar path? Will developers make use of these retrofitted features in Java 7 en masse or will it  initially be adopted by framework developers like Neil Gafter's closures protoyype example as applied to Doug Lea's Fork/Join concurrency framework? Or will developers continue to move to other languages that are more suited for these features like Scala, Groovy, etc.

Assuming Neil's closures proposal wins out and I think it looks likely because James Gosling pretty much stated as such, pointing out how it should have been all or nothing in the first place (with regard to anonymous classes), will the ugly static types in the closures syntax scare off developers? Alex points out in a follow up comment that it is best described  by Josh Bloch's JavaPolis presentation this past week:

http://www.javac.info/bloch-closures-controversy.ppt

Update: Neal responds to Joshua's criticism: http://gafter.blogspot.com/2007/12/what-flavor-of-closures.html



Or is the BGGA proposal merely a great source for more Java Puzzlers from Neil? ;-)

For those new to closures, here's an example illustrating multiple return types (culled from Bruce Chapman's "Closures and Multiple Return Values"):

import static java.lang.System.out;

public class MultipleReturnClosure {

  public static void main(String... args) {
    toPolar(3,4,{double r, double theta =>  out.format("3,4 = %f<%fRad%n",r,theta);} );
  }

  static void toPolar(double x, double y, {double, double => void } rThetaReceiver) {
    rThetaReceiver.invoke(Math.sqrt(x*x + y*y), Math.atan2(y, x));
  }
}

The example above is really a continuation with closures example with the key to understanding the code being: rThetaReceiver "receives" r and theta.
Or of course, you can do the following right now without closures:

import static java.lang.System.out;
import java.util.*;

public class MultipleReturnMap {

  public static void main(String... args) {
    Map result = toPolar(3,4);
    out.format("3,4 = %f<%fRad%n",result.get("r"),result.get("theta"));
  }
  static Map toPolar(double x, double y) {
    Map<String,Double> result = new HashMap<String,Double>();
    result.put("r", Math.sqrt(x*x + y*y)); result.put("theta",Math.atan2(y, x));
    return result;
  }
}

Which will your average Java developer choose in the coming year or two? Yes, I know the other two or three proposals may make it more readable but there there are still compromises. The point here being that just as some developers didn't embrace advices and consequently AOP initially, will they also wait for these constructs to be supported within framework APIs first?  Perhaps what is needed here are convincing usage examples that illustrate productivity and maintainability gains for the average programmer (and as Joshua points out, performance is still an open question). Otherwise for specific domains, we'll see a continued migration to other languages where these features are a better fit.   Will these Java 7 features provide more flexibility? Like Alex, I don't know the answer to that question yet either.

---

Post Script:

Alex continues with additional thought here (thanks Alex) : http://tech.puredanger.com/2007/12/15/to-closure-or-not-to-closure

As requested in comment below, here are some short examples of a couple ideas for extension methods:

Neal Gafter's proposal for extension methods:
"Closures Prototype Update and Extension Methods"

example:

import static java.util.Collections.sort;

…

List<String> list = …;

list.sort();

and Peter Ahé's response:
"Declaration-Site Extension Methods"

example:

package java.util;

interface List<E> … {
  …
  void sort() import static java.util.Collections.sort;
  …
}

And for type inference see Elliotte Rusty Harold's post:
"Type Inference: Another Bad Idea for Java 7"