I've been reading a lot lately about the next release of Java possibly supporting closures. I feel like I have a pretty firm grasp on what closures are, but I can't think of a solid example of how they would make an Object-Oriented language "better". Can anyone give me a specific use-case where a closure would be needed (or even preferred)?

+2 if i could. This is the 'missing link' in discussions about java closures. Deserves a question of it's own, Rainer.

This is the best description of a closure that I have encountered. I understand now why the new closure implementation is being limited to local only. Danger Will Robinson, Danger!

+1 Now I understand why Joshua Bloch says Java already has closures ( in the form of anonymous inner classes ) After reading what you said, I agree. The problems with a.i.c is they are way to verbose.

How does one perform type safety with a closure? Surly an abstract anonymous class is clearer than a closure?

-1: "They don't make an Object-Oriented language better. They make practical languages more practical.": I strongly disagree with this principle. Maybe closures will make Java more practical, but in principle one should not sacrifice the coherence of a language just to make it "more practical". IMO there must be another, stronger motivation for introducing closures. A language that has a very heterogeneous semantics and a lot of special cases just to be "more practical" is more difficult to learn. Programming languages should be based on concepts not on idioms.

Thanks for reinforcing my suspicion that closures would just be syntactic sugar for anonymous inner classes.

If they were as complete as JavaScript/C#/C++0x closures, they would be more powerful than anonymous inner classes, because they would be able to capture modifiable references to local variables, not just readonly copies of finals.

Daniel Earwicker: You can simulate this by wrapping the modifiable variable in a container object (putting it on the heap) which is then assigned to a local final var.

Bart van Heukelom - you can indeed, or even better, you can use a language that does this for you! :)

Bill: Closures are NOT the same as anonymous functions or inner classes, though the differences are subtle. See

Agreed, just for convenient map/filter implementations it would be worth it. Not to mention most uses of anonymous inner classes. Readability and code size counts.

Upvoted for knowing (and explaining) the distinction between closures and functions as values

note that the difference is much smaller when you use anonymous classes

Michael Borgwardt, note that the difference is much more bigger when you have allot of closures and composition of functions.

I think "spell everything out the long way" would be more accurate as "spell everything out explicitly" (at least in my case). There is a subtle difference.

Well - I'd say the two are distinct cases with a large intersection. So perhaps if we talk of the union of those two we get to the knub of it :-)

First-class functions are a distinct idea from closures. The former refers to treating a reference to a function (or the function itself) as a value -- one that can be passed around and invoked at will. The latter is concerned with capturing references to values available lexically at the point of definition and extending their lifetime through the lifetime of the function created there. One can have first-class functions without having closures, though I don't think the converse makes sense.

Well, they are distinct ideas, but one is based on the other (hence the lack of transitivity in your final comment). I said that, "Closures promote the concept of the function-as-object to a first class entity" - not that they were the same thing. The fact is, as it stands, Java does not have a proper concept of first class functions, but if it got Closures it would get that too as a pre-requisite. That's really what I meant. But if that wasn't clear it's good that you've clarified it with your comment :-)

When you raise the level of abstraction you are introducing new semantics not just using syntactic sugar. Java is not syntactic sugar over assembly.

This doesn't answer the question, but +1 for your suggestions! Personally, I do use Scala, and its functional programming is great.

Thanks for the suggestion and the vote. Maybe I should have made my statement more explicit: I think that Java does not need closures and that this extension will make the language unnecessarily complex.

I think you are right about that. I think that Java never had functions as objects because Sun didn't want it like C's function pointers (or so I read in Core Java 2). However, there are ways of implementing functions as objects that do not involve function pointers. Again, Scala is the best example of that.

I just bought my Scala book, staring to read it and I like it a lot! Definitely, I think one should not fumble around with a language like Java or C++, which were not designed to support FP. Java remains one of my favourite language, but if one wants OOP + FP one should look at a language that was designed for that.

Lexical scoping and Variable Capture from The State of Lambda are great reads; but "effective final", IMHO, is not such a good idea, the compiler probably needs an extra pass to determine "effective finality" and also code that compiles today starts breaking tomorrow b ecause a newly coded line "miles" away from the closure converted the reference to mutable.

UstamanSangat My understanding is that all free variables in a closure, in Java, are effectively final whether you declare them explicitly or not. I have not read the translation strategy in a while, so I do not know if this is just a compiler thing or if it is instrumented in the JVM somehow.

Agreed, my point was mostly about a new line of code 20 lines away from the closure changing a previously effectively final variable to a mutable one. When that code doesn't compile, a less sophisticated developer might get confused. But I think an IDE can always help.

By "abstract class" you mean aonymous inner class?

I think this is the proposal you're referring to.

yes, Tom - I do mean that - sorry And that looks like it Bill - thanks

Just to be clear, my question wasn't intended to argue in favor of blocking the inclusion of closures. Also, I would have agreed with the "non-essential" argument for one of the features you mentioned above. :)

Many features are not essential. However, IMHO one should look at how often a feature is going to be used compared to the complexity it adds to the language semantics and tools.

It is the first link return by google search for java closure example

Are you speaking from experience? My experience has been exactly the opposite.

Edwin Dolarzo's links are great to read. Need to know what approach are already taken by Scala and Groovy and others