Look at JSR 241 <http://jcp.org/en/jsr/detail?id=241>.
Particularly to closures <http://groovy.codehaus.org/closures.html>.

I wish I could code this way Runnables, PropertyChangeListeners, ... all typical single method annonymous inner classes that clutter my code.
  xxxxx@xxxxx   2004-03-16
  xxxxx@xxxxx   2004-03-16

N/A

I've been saying this for more than seven years.


Closures are a great thing.  Unfortunately, Java missed the boat in 1997.

Since then, we've added a collections framework without closures (one of the prime uses), built graphics APIs around nested classes etc. We have tons of control constructs that could be defined using closures but aren't (assert 
and foreach, for example).

So the advantage of adding closures now would be relatively small compared
to the huge benefit you get if you add them from day one.

Implementing them is quite painful (though I think I've worked out how to
do it) without VM support. And dealing with all the special cases  around
break, continue etc. is a mess.

So, it's too late for Java - the costs are higher than they should be, the 
benefits lower. Sigh.

In short,
  xxxxx@xxxxx   2004-07-09

Closures in java would go hand in hand with delegates (id 4483171)

Implementation of closures might be  easy if it is translated into an anonymous inner class, then it wouls also work directly with exsisting awt/swing hooks.
That way no jvm level changes are needed.

i would suggest this:
new Runnable.run() { }

how its now:
new Runnable() { public void run() { } } 

a limitation is that it would only work for interfaces because you can t specify constructor parameters.

We can use anonymous inner class to workaround closures. However if would be nice to add some level of support directly from the language.

The syntax is one thing, but what makes closures really handy in other languages is that you don

A syntax that minimizes the difference w.r.t. current VMs and 
  public function interface XXX {
	void XXX(int x);
  }
where interface name and method name MUST be the same, and the interface MUST contain one and only one method.


Then the invocation syntax becomes:
  something.apply(new function XXX(int x) {  
    System.out.println(

From evaluation:

"Since then, we've added a collections framework without closures (one of the prime uses), built graphics APIs around nested classes etc. We have tons of control constructs that could be defined using closures but aren't (assert 
and foreach, for example).

So the advantage of adding closures now would be relatively small compared
to the huge benefit you get if you add them from day one."

It's quite possible to implement closures as a syntax enhancement, allowing any old code to use it, just like happened with generics. Please, consider the following:

Written code:

import java.util.*;

class MyClass {

  int onCompare(Object o1, Object o2) {
    // My stuff here.
  }

  void sort(List list) {
    Comparator c = closure Comparator(onCompare);
    Collections.sort(list, c);
  }
  

}

Generated code:

import java.util.*;

class MyClass {

  int onCompare(Object o1, Object o2) {
    // My stuff here.
  }

  void sort(List list) {
    Comparator c = new Comparator() {
      int compare(Object o1, Object o2) {
        return onCompare(o1, o2);
      }
    }
    Collections.sort(list, c);
  }
  

}

Currently we can use anonymous inner classes to fake a closure.  The example I give requires extending the List interface to support a void each(Closure) method.

Here is the Closure interface:

public interface Closure<T> {
  void execute(T object);
}


Here is the extra method added to the List<T> interface:

  // Executes the 
  void each(Closure<T> closure);

// assume we have a List of Items in stock and 
// we need to count how many items are priced over 50 dollars.

List<Item> itemsInStock = getItemsInStock();

final int[] count = { 0 };

itemsInStock.each(new Closure<Item>() {
  public void execute(Item item) {
	if (item.getPrice() > 50) {
		count[0]++;
	}
  }
});

The syntax is painful, but not as painful as the use of the final array to allow the anonymous inner class to use a variable in the method scope.  What we would really like to do is this:

List<Item> itemsInStock = getItemsInStock();

int count = 0;

itemsInStock.each({ | Item item |
	if (item.getPrice() > 50) {
		count[0]++;
	}
});


Much cleaner, and no annoying hack for the final variable.  Vote for this.

I have no qualms about Java implementing the feature as inner classes under the bonnet, or silently converting 'int count' to 'final int[] count = {0}' .  For now, this change can be implemented at the language level: no VM changes shoould be necessary, although if they can be implemented 'natively' in a nice clean and efficient manner, all the better.

Also, can anyone from Sun confirm the accuracy of the following information at the following URL: http://article.gmane.org/gmane.comp.lang.lightweight/2274

>> I've been saying this for more than seven years.


>> Closures are a great thing.  Unfortunately, Java missed the boat in 1997.

>> Since then, we've added a collections framework without closures (one of the prime >> uses), built graphics APIs around nested classes etc. We have tons of control >> constructs that could be defined using closures but aren't (assert 
>> and foreach, for example).

>> So the advantage of adding closures now would be relatively small compared
>> to the huge benefit you get if you add them from day one.

>> Implementing them is quite painful (though I think I've worked out how to
>> do it) without VM support. And dealing with all the special cases  around
>> break, continue etc. is a mess.

>> So, it's too late for Java - the costs are higher than they should be, the 
>> benefits lower. Sigh.

>> In short,
>>  xxxxx@xxxxx  2004-07-09

I would have thought that making collections support closures would be an 'additive' operation.... it wouldn't break existing functionality.  Adding select(Closure) and each(Closure) etc methods class will not break anything else.  Sure, I am sure that there is tons of existing code in the JRE libraries that searches through collections without using closures but so what?  New code can use it, and if you want to clean up the codebase, refactor all of the old code to use the new stuff.  You could probably even whip up a custom refactoring tool to do it automatically while preserving behaviour for mot cases.  

For one thing, I don't really give a damn as to how the internals of the JRE actually work.  I care that they DO work, and that the public API is clean.  Adding Closures is great for all of us developers that write applications in Java.  You guys at sun can do whatever you like!

P.S.  I am actually interested in what assert, break, continue etc has to do with closures though.  Please enlighten me :0)

 The main benefit of closures over inner classes seems to be a reduction in typing, you can reduce the verbosity of declarations by:

1. Make the new keyword optional.

EG instead of:

String s = new String();


Allow:

String s = String();



2. For methods and classes make the curly braces optional if there is only one statement. IE like for, if, etc.

EG instead of:

class IntWrapper {
    public int i;
}


Allow:

class IntWrapper public int i;



And instead of:

public String toString() {
    return "Hello";
}


Allow:

public String toString() return "Hello";



3. If a class needs to only implement a single method that is defined in either an abstract class of an interface, then allow the method qualifiers, return type and name and the arguments types to be omitted.

EG instead of:

class MyAction implements ActionListener {
    public void actionPerformed( ActionEvent notUsed ) {
		textArea.append( textField.getText() );
	}
}


Allow (only using simplification 3, see below for an example using all 3 rules):

class MyAction implements ActionListener {
    ( notUsed ) {
		textArea.append( textField.getText() );
	}
}




Now an example of combining all three rules, instead of:

textField.addActionListner( new ActionListener() {
    public void actionPerformed( ActionEvent notUsed ) {
		textArea.append( textField.getText() );
	}
});


Allow (using all 3 simplifications):

textField.addActionListner( ActionListener() ( notUsed ) textArea.append( textField.getText() ); );

This would seem to satisfy those wanting shorter syntax and would be backwards compatible.

For Closures to work safely, they cannot simply be implemented as an inner class. Any local variables declared before the closure must be accessible by the closure, but they must not be modifiable by separate threads. Otherwise you'd have to add new synchronization support for guarding access to local variables, which simply doesn't make sense.

Closures would have to be restricted such that references to them can never escape the current thread of execution. The compiler and verifier would need to make sure that a closure reference is never saved to a field.

This restriction ensures that closures behave properly, but it means that they cannot be used as a general purpose replacement for event handlers or delegates.

Inner classes only allow access to final local variables, this makes them safe to use in threads (but not necessarily thread safe in the normal meaning of the term). The same could be done for a closure.

If the Closure required out-of-scope local variables to be final, then its not terribly useful. The ability to modify local variables outside the Closure's scope is a key feature.

It is easy to wrap a local in a class or array if the closure requires write access to it. The compiler could also do this automatically (I think C# version 3 will automatically wrap). Same goes for inner classes - see my post above re. shorter syntax as an alternative to introducing closures.

>>i would suggest this:
>>new Runnable.run() { }
>>
>>how its now:
>>new Runnable() { public void run() { } } 
>>
>>a limitation is that it would only work for interfaces
>>because you can t specify constructor parameters.

Why not allow:
 new SomeClass(c_args).someMethod(m_args) { foo(); }

which would be the same as:

public AnonymousClass extends SomeClass {
    public void someMethod(m_args) {
        foo();
    }
}

Where "public void" on someMethod is discovered from the access and types of SomeClass.someMethod(m_args).  This seems to be a small change to how inner classes are currently implemented.

I do not want closures in Java SE 7.

Closures in Java are a good thing

It will make the language more complex, but the alternative 'anonymous inner classes' make the application more complex and this is worse. So what often happens is that anonymous inner classes are transformed to normal inner classes, or even normal classes. So the lack of closures increases the amount of noise!

Java need closures, Already all the languages include it, Even for god sake PHP 5.3 have closures. C#,VB.net, Python,C, C++, Ruby, PHP, Haskell, Smalltalk, Lisp etc etc have closures.

I think Closures is part for the modern programming languages, If Java doesnt include closures it will fell down and to the bottom maybe really will become more worst than Cobol is it now.

To many mistakes has been and  I think now is good time to fix all this mess and include Closures and we need a proper event driven development in Java.

I thought SUN was the innovative and cool company but since the end of the 90's all changed, Microsoft it is doing pretty cool with C# 3 and .Net, If this doesn't resolve soon I will have to leave Java and go with C#. I dont want to live everyday with an outdated programming language.

Let closures be there. if someone does not want it, let them not use it 

Please DO NOT include this feature. Wake up! Its Java. The Java we loved many years ago. And the same we love today. Simple. As it should be.

I'd like to vote against this feature.

100 vote :-)

I vote for this feature !

I'd like to vote against the inclusion of closures in Java. 

This evaluation is completely floored basing an argument on that just because Sun has developed some set of APIs ( some of them terrible i.e. Date, Calendar, Properties etc ), then the expansion to adopt closuers is useles. Does the Author of the comment ( If still here , I hope honestly not ) seriously think that 

a) Sun writes the most used API's ? 
b) That the majority of Java code in the world is somehow already been written. 

Also look at what happend with the introduction of Generics. Good Sun inhouse APIs power was enhanced ,such as Collections, with their usage.

Regardless of the opions of whether Closures are a good idea, I would like it noted that the evaluation is senseless and more so dangerous, and I would be unhappy that someone with such small minded opions has any say in such a critical decision.  

I am voting against of this! 

I want closures!

Better link to understand closures:
http://en.wikipedia.org/wiki/Closure_(computer_science)

C# has delegates that "acts" like closures. I've used them a lot, and seems pretty good to me.

I've been sold on including closures -- as long as this is done well the first time.  The devil is in the details.

That said, part of the BGGA proposal, exception transparency, strikes me as more important than closures in some respects.  It does a lot to alleviate limitations that arise with generic algorithms, e.g. a visitor pattern, with checked exceptions.  Sure, Neil Gafter says it is the hardest part of BGGA to implement.  On the other hand, conceptually it just smooths some rough edges with checked exceptions and generics; simplifying life without complicating it.  Thus this part of BGGA seems like a high-priority no-brainer addition to me.

As for the rest of closures, there are lots of bits to get right, including pesky syntax.