Java closure types, variables, arrays and collections

Question

What is the current state of spec for Java closure?

1. In the proposed Java closure spec, would we be able to create an array or collection of closures?
   If so, would this syntax be possible?

   {int x, int y => boolean b}[] comparisonSwitch = {
     {int i, int j => return i>j},
     {int i, int j => return j<i},
     {int i, int j => return j==i}
   }
   
   boolean compare(int acase, int a, int b){
     return comparisonSwitch[acase].invoke(a,b);
   }
   

2. Would normal methods be considered as non-anonymous closures?
   So would the following syntax be possible?

   public class Asdf
   {
     public boolean gt(int x, int y){
       return x>y;
     }
     public boolean lt(int x, int y){
       return x<y;
     }
     public boolean eq(int x, int y){
       return x==y;
     }
   
     {int x, int y => boolean b} GT = gt;
     {int x, int y => boolean b}[] comparisonSwitch = {
       gt, lt, eq
     }
   }
   

3. i.e., are closures and methods interchangeble operationally?
   Would the following syntax be allowed?

   // declare a method that has a closure type as an argument
   void closurator( {String s => int a} findlen ){
     // do whatever
   }
   String s = "hello";
   void useClosurator(){
     // invoke the method by supplying a non-anonymous method
     // of an object
     closurator(s.indexOf(String ss));
   }
   

4. How would we be able to specify a closure type in an interface?
   Could we do the following, effectively declaring final/constant reference to methods.

   interface Closuration
   {
     public class Asdf
     {
       static public boolean gt(int x, int y){
         return x>y;
       }
       static public boolean lt(int x, int y){
         return x<y;
       }
       static public boolean eq(int x, int y){
         return x==y;
       }
     }
   
     {int x, int y => boolean b}[] comparisonSwitch = {
       Asdf.gt, Asdf.lt, Asdf.eq
     };
   }
   

5. Since closures would access code space, just as reflection would, would use of closure slow down the performance of a programme? If not, would it mean, that reflection would be sped up by borrowing advances made in "closure technology"?

Inserted new question: Actually, would closure code be part of code space or in the variable heap, because I am predicting that closure code would be susceptible to be wiped off by garbage collection, right?

May I request you to focus on the gist of the questions, not on any syntax errors/typos/missing keywords in the example code. Any typos/errors, please correct them for me. Thank you.

Answer 1

You're asking about the JDK7 closures work, so references to javac.info are not relevant. That site is about the now-completed openjdk closures project, which showed how to add transparent closures to Java - transparency in the sense of satisfying Tennent's Correspondence Principle and described roughly in my blog.

The effort for JKD7 is organized under the openjdk lambda project. The specification is undergoing rapid evolution, so any answers are tentative. As Tom Hawtin pointed out, here is the latest draft spec.

Before answering your specific questions, it is worth observing that Java has separate namespaces for variables and methods. Consequently, there is likely to be some syntactic distinction between invoking a method and invoking a variable of function type (in C# parlance, a delegate). Similarly, it is unlikely you will be able to refer to a method by just naming it, as you would to refer to a field.

To answer your questions:

1. That is not the proposed syntax for a function type. Setting that issue aside, you're wondering if it will be legal to have an array of function type. The current draft specification suggests that the answer is yes, but the known implementation strategies would result in a hole in the type system unless "array of function type" is somehow disallowed. The draft specification carefully avoids discussing implementation strategies. It is possible that VM spec changes could be made to address these issues. If I had to guess, I suspect the answer to your question will be "no". However, you would be able to achieve the same effect using java.util.List instead of an array. Given that the separate project Coin is considering adding Collection literals and indexing operations for List, it is likely to be just as syntactically convenient.
2. You're wondering if you will be create a function-valued expression by naming a method. Because (among other reasons) methods and variables appear in different namespaces in Java, the answer is probably no. However, it is possible that the specification will be extended with a specific syntax for asking that a method name be treated as a function-valued expression. See the section Method References in the document Closures for Java (v0.6a) for one way that might be considered, using a syntax proposed by Stephen Colebourne. This is not yet in any draft of project lambda.
3. See answer to (2).
4. See answer to (2).
5. You're concerned about performance. In short, it is unlikely that closures would be implemented with any techniques that cause them to be much more expensive to invoke than a method. No VM changes are required for performance reasons, though they might be a good idea for other reasons (see answer to 1). See the Closures Project homepage for a pointer to a prototype of BGGA, a more ambitious closures specification, which runs on stock jdk5/jdk6, and whose performance you can measure.

Answer 2

Closures in JDK7 are short on detail at the moment. In the presentation at Devoxx the examples used were very similar to the FCM closures proposal.

Assuming that spec is used in JDK7 then I think the answer to parts 2, 3 and 4 of your question is yes (although I could well be wrong).

For part 1 - I think it should be possible to have arrays since method literals are assignable to Method objects.

For part 5 I would suspect the performance would be similar to inner classes.

Sorry I am being a bit vague - I hope it helps a bit. It is probably still to early to answer your questions with certainty.