The use of closures and first class functions looks neat in Python and other languages, but the syntax proposed here is bearly legible - even in the simplest example. Remember the confusion on your first attempt at implementing a class with a generic interface? Yikes.

Why do I get the impression closures will be forced upon the Java language for all the wrong reasons? Please don't sacrifice Java's easy-to-read syntax for the sake of looking 'cool' to the vocal minority. While closures make for scripts with some neat tricks, they can also lead to some horrible spaghetti code in larger code bases. Lets just keep Java simple. Or least legible.

I've long wanted closures for dealing with anonymous classes for AWT/Swing action handlers and one-off threads that I have to use to get things off of or back onto the event-dispatch thread, both of which are tasks that sometimes require the incredible ugliness of declaring a final variable just to make a local variable visible to the thread. When I saw closures in Ruby, I immediately realized that this was a valid Java use for the concept.

Java 1.7 should actually be Java SE 7.0 (Dolphin).

I don't know. Closures and lambdas are great -- and I agree with Chris that it would clean up the syntax in some of the tossing of Runnables around, however I am going to go out on a limb here and say we just don't need it so much.

Much like a lot of the talk about invokedynamic, I don't think we need this so much as just cleaning up what we already have. About 90% of what people seem to want invokedynamic for looks to me like something that could be solved by letting people create DynamicProxies of Objects. Here it seems that just having a more reasonable Reflection API and some more sane definitions for taking care of this stuff.

It is not that closures are inherently bad, I just really tend to feel they make code less maintainable as you get to end up hiding "real" code in hard to find places.

In terms of the proposed syntax, it really doesn't seem like a big step down from Pythons closures at all, just with the return types cast. Certainly not as bad as the "XML in the language" proposals I have seen.

The syntax is horrible. "Thou shalt not add reserved words to Java" is getting annoying.

Ok, seriously, someone tell me why:
int plus2(int x) { return x+2; }

is SOOO much worse than:
def plud3 (x): return x+2

Closures are alright. There are definately times when they are needed to keep a clean interface. But I'm sure they will be misused more often. By all means put it in there, but how about making Java SE leaner first.
And while you are at it lets have a homogenous single point of configuration for Java apps, rather than the gazillion of configuration files. A simple pluggable set of _interfaces_ for loading and accessing the configuration.

You can play with closures in java already; groovy provides this: http://groovy.codehaus.org/

/Lars

"If you evolve a language far enough you destroy it." - Josh Bloch

Closures are already 90% solved by interfaces and anonymous classes, and the latter are actually more strongly typed and cleaner. I am personally against adding more features to the language that decrease readability with very little benefit. Generics has already made a mess of things.

Closures are already 90% solved by interfaces and anonymous classes, and the latter are actually more strongly typed and cleaner. I am personally against adding more features to the language that decrease readability with very little benefit. Generics has already made a mess of things.

We are creeping ever-closer to the cliff that upon falling from, will see us tumble into the syntactic abyss/nightmare that typifies the living Hell of the C++ programmer. Weren't we Java-gnomes the ones who didn't want this kind of complexity and thus the two main selling points of Java -- readability and ease-of-use -- are now at risk of being lost so some folks can have their wee programmatic nifties? Ugh. Go code in C++ if you want to be a full-bore weenie, but for the love of God, leave the rest of us out of it.

Interestingly how much venom this idea has attracted from some people. I don't like the horrid syntax, but that's mainly the ridiculous amount of static type stuff that's needed. And yes def plus3(x): return x+3; is easier on the eyes than int(int) plus2b = (int x) {return x+2;};

I'll be tracking this development closely - and hope that a nicer version is actually implemented.

Less is probably more in this case(plus it looks pretty ugly)

int plus2(int x) { return 2 + x; } // legacy style
int(int) plus3 = (x) { return 3 + x; } // closure style
int(int) plus2b = plus2;
int(int) plus3b = plus3;
plus3 = plus2; // OK, compatible type and plus3
// is a closure
plus2 = plus3; // Illegal, plus2 = legacy

Please!!..NO. Don't complicate the lang sytnax. Java's beauty is the simplicity in lang. Why do they spend most of the hour in doing the syntax thing but not spending enough time to fix those bugs which have been stucked for years, especially the problems on desktop deployment. Why we need to ask clients to download 20M of JRE to run our 400k applet? Yes, it is downloaded once and for all but no customers would love to install something as big as 20M for their occational usage. Why does it just do what the flash plugin do? Just have a client vm with graphics mostly and do the show. Take out unneeded stuff and chop it small enough (1 - 2M). What the flash platform does is to gain the battle field in controlling the desktop market first and seed your BIG VM (apollo) there afterward. Then you are all set.

NO!! This will cause nothing but issues and as other people have pointed out is not an absoluate necessity. KISS

So Java is going to run a full circle and end up as complex and as unmaintainable, and as easy to shoot yourself in the foot as C++.

And then a small community (or perhaps another "visionary" company) will come a long and simplify Java to something else nice, small, easy to learn and productive. Such is life.

Is Java 1.7 trying to compete with Linq/C# 3.0

I've done both Java and C# development, and closures/anonymous methods have been really nice in my C# endeavors. Sure they can be abused and misused, but so can a lot of things. You can't force bad developers to write clean code no matter how simple the language is. Closures do server a purpose, but like anything they can be abused. But I guess I'm a little biased in my opinion, I also LOVE generics... :)

Seems like a new keyword is needed:

public static void main(String[] args) {
int plus2 (int x) { return x+2; }
function(int, returns int) plus2b = plus2;

System.out.println(plus2b(2));
}

closure:

function(int x, returns int) plus2b = function(int x, returns int){return x+2};

A little more verbose, a lot more readable.

BTW, I thought for(Ojbect o: objs) {} syntax wasn't very readable at first, but for loops are used all the time, so it's easily readable now.

Closures in Java would typically follow this ... ( as per my understanding )

{ int , int => int } ( takes two ints and yields an int

But invariably closures can give java most powerful features ... like for example i could have a complex closure like { { int x, int y => x + y} ,{int z, int a => z + a} => int zbc }, wherein we have two closures yielding an int and both taken as args and yields a final int zbc. or something to that sort ...

very intuitive and powerful. the closure result will be an object type ...

in response to anonymous code about spaghetti code, closures are being added because :

we have anonymous classes which are inherently weak. For example you cannot use the variable in the same way inside a lexical scoping ( the scoping of the anonymous class that is ). Example i declare a variable x = 100; and then in anonymous class i gotta access that variable do some calculation, then i have to make the modifier of x final ... why all of this required, when an elegant solution will give me all i need ...

thats the thought behind closures ...

Vyas, Anirudh

I agree with Venant. Fix the bugs and the current issues with the platform rather than adding new features. Keep Java Simple. If you want closures use Groovy.