But in my annotation-like proposal just above, I think the code should just be injected around the block. Defining the code would be something like this:

@interface (or @class or @aspect?) TimedOperation (?implements @Aspect?){
    Advice around() {
     ///some code
         proceed();//do the block
    //some more code
    }
}

Using it would be:

@TimedOperation() {
   //your block
}

I think this would be more java-like than the first proposals, because you are somehow using a class-like construct rather than passing functions to functions.

-- Main.tobega - 12 Sep 2006

So if we instead focus on the problem of re-using try/finally boilerplate, then closures may not be the only answer. There may instead be an answer that has less danger of being abused. Perhaps something annotation-like that allows inserting code around a block (in somewhat an AOP-like fashion, I suppose).

So something like: @WithTransaction(transaction=myTransaction) { //do whatever }

Now we just have to find a nice way to define the code that WithTransaction^? will surround the block with.

-- Main.tobega - 05 Sep 2006

The other one, the synchronous, is the new abstraction we don't have yet and it's enormously powerful. The problem I see is the ugly syntax of the method that admits closures as arguments. I would propose a starting point for this syntax that is not so "C function pointer"-based. It would be something like this:

public void foo(int arg1, String arg2, {int} myBlock(int x, double y) throws Exception){
  // ...
}

or

public void foo(int arg1, String arg2, {} myBlock(int x, double y):int throws Exception){
  // ...
}

I'm not totally satisfied with my own proposal, I still see it's a bit ugly, but I think it's clearer with the starting '{}' that the argument is a block of code. I wouldn't use function types in Java if we can avoid it. Remember that this syntax is for the synchronous use case (not the inner class based one), so it has to be remarked at first sight that what we are passing as a parameter is a block of code with parameters (and that it can throw an exception).

You can refine this proposal of syntax, this is only a starting point.

-- Main.xmirog - 05 Sep 2006

Syntax: Samples of Possibilities

Anonymous Inner Classes

One use-case for closures is to reduce the need for anonymous inner classes. The following is from Neil Gafter, in Neil Gafter's Blog: Use cases for closures. As Neil puts it, If this syntax doesn't mean anything to you, just imagine that the block appearing at the end of the invocation of ex.execute is turned into a closure and then passed as the last argment (the only one, in this case) to execute. That's basically what the abbreviated invocation syntax does.

Syntax without closures

void sayHelloInAnotherThread(Executor ex) {
    ex.execute(new Runnable() {
        public void run() {
            System.out.println("hello");
        }
    });
}

Closure Syntax

void sayHelloInAnotherThread(Executor ex) {
    ex.execute() {
        System.out.println("hello");
    }
}

Simplifying Comparators

Posted by Patrick Gotthardt in JavaLobby: "(Regarding Closures) Think About Java-Joe!", here. Patrick's example shows how a sort can be simplified by using a closure to replace a Comparator.

Syntax without closures

List<Person> persons = ...;
Collections.sort(persons, new Comparator<Person>() {
   public int compare(Person a, Person b) {
      return a.getAge() - b.getAge();
   }
});

Closures Syntax

List<Person> persons = ...;
Collections.sort(persons) int(Person a, Person b) {
   return a.getAge() - b.getAge();
}

Filtering Lists

From Ray Cromwell, in JavaLobby: "(Regarding Closures) Think About Java-Joe!", here.

Syntax without Closures

findDivisibleBy(List<Integer> l, final int div)
{
  return filter(new Predicate<Integer>()
                {
                       public boolean exec(Integer arg)
                       {
                            return arg % div == 0;
                       }
                });
}

Closures Version (1)

findDivisibleBy(List<Integer> l, int div)
{
   return filter(boolean(Integer x) { x % div == 0 }, l);
}  
findDivisibleBy(Arrays.asList(1,2,5,6,9), 3) => [6,9]

Closures Version (2)

findDivisibleBy(List<Integer> l, int div)
{
   return filter(l) boolean(Integer x) { x % div == 0 };
}  
 
findDivisibleBy(Arrays.asList(1,2,5,6,9), 3) => [6,9]

Various:

TODO: from Ray Cromwell on JavaLobby: "(Regarding Closures) Think About Java-Joe!", this posting.

Discussion on Syntax

This section is meant to capture discussion. There are several discussion threads already open, see above. You're welcome to add examples of how closures (look like they) would work in Java 7, and comparison with other languages. All I ask is that you avoid purely derogatory comments, or language-related flame wars, or other nonsense. If you don't like Java at all, this is not the page for you. If you think closures are a bad idea because there are better ways to express the same thing, or reasons not to use them, please give examples.

Please sign examples as well with your id, so others can reference them.

By analogy: I can understand the concept of an SUV, without agreeing that they are a good thing.

About the example:

Does using CharSequence^? in the above example improve its readability? Certainly not for those of us who started on Java before 1.4. (CharSequence^? is a new interface which String implements since 1.4)

And is the standard form of the closure in the discussion representing a false economy? We look at:

Object(Object) identity = (Object ob) { return ob; };

And think, gosh, that is much shorter than the three line anonymous inner class! But when the inner class example is putting the braces on their own lines, is it a true comparison?

Shouldn't we advocate it thus:

Object(Object) identity = (Object ob) {
  return ob;
};

Or should we alternatively change the anonymous inner class code to match the formatting of the closure code?

Instead of:

Trans t = new Trans() { 
  Object identity(Object ob) { 
    return ob; 
  }
};

Should we say:

Trans t = new Trans() { Object identity(Object ob) { return ob; } };

And is

CharSequence^?(CharSequence^?) identity = (CharSequence^? seq) { return seq; };

Actually all that more compelling?

It turns out that if we use really long class names and strange formatting we can make any example look bad. If we use object instead of CharSequence^? how many keystrokes do we save?

Trans t = new Trans() { Object identity(Object ob) { return ob; } };

vs

Object(Object) identity = (Object ob) { return ob; }

(68 + 8 (shifts for punctuation) keystrokes) vs (52 + 6 keystrokes)

And of course you save the 'enormous' effort of defining the Trans class/interface.

public interface Trans { Object identity(Object ob); }

In the example code does the use of the static keyword indicate that we are supposed to have some kind of 'library' class which just contains closures for other classes to use? That strikes me as a bad programming practice to encourage.

Is it just in there for convenience, or as an oversight, or is there a good reason, will the use of static be an integral part of closures, or is it orthogonal to the example?

--Main.rickcarson - 29 Aug 2006

• JavaLobby: "(Regarding Closures) Think About Java-Joe!"

• Neil Gafter's Blog: Use cases for closures

• Tom Ball's Blog: Are Closures Just Delegates?

• Artima: "Bill Venners: Seeking the Joy in Java"

• Tom Hawtin's Blog: The Closure Proposal

• Forax's Blog: Closures and Performance

Modifying Array Contents

  static CharSequence[] transform(
    CharSequence(CharSequence) transformation,
    CharSequence... array
   ) {
    for(int i=0;i<array.length;i++) {
      array[i]=transformation(array[i]);
    }
    return array;
  }

applying a transformation

CharSequence(CharSequence) identity = (CharSequence seq) {return seq; };
CharSequence[] seqs=transform(identity,"2","3");
System.out.println(Arrays.toString(seqs));

and overloading parameters

String(Object) bang = (Object o) {return "!"+o; };
CharSequence[] seqs2=transform(bang,"2","3");
System.out.println(Arrays.toString(seqs2));

Closures Syntax in Java 7

There is a proposal floating around by Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé on adding support for closures to the Java language in the Java 7 release.

PDF with proposal draft

This page is to collect

• links related to the proposal
• commentary on the proposed syntax
• samples of how the syntax would look

Links

Proposal

• PDF with proposal draft

Blogs

• Neil Gafter's Blog: Closures for Java
• Neil Gafter's Blog: What's the Point of Closures?
• Gilad Bracha's Blog: Achieving Closure
• Peter von der Ahé's Blog: Full Disclosure

Discussions

• JavaLobby: "A proposal for closures in Java programming language"
• JavaLobby: "Neal Gafter: What's the point of Closures?"

Discussion on Syntax

This section is meant to capture discussion. There are several discussion threads already open, see above. You're welcome to add examples of how closures (look like they) would work in Java 7, and comparison with other languages. All I ask is that you avoid purely derogatory comments, or language-related flame wars, or other nonsense. If you don't like Java at all, this is not the page for you. If you think closures are a bad idea because there are better ways to express the same thing, or reasons not to use them, please give examples.

Please sign examples as well with your id, so others can reference them.

-- Main.pdoubleya - 22 Aug 2006