For those that missed it, it was announced that the final syntax for Java Closures has been agreed (will be part of Java 8 ).
http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html
After all the years of debate, flamewars and articles, they just decided to use the same syntax as Scala and C#.
Can someone tell me why closures are so awesome? They cause me so many bugs in javascript.
Thank god!
@Eli
I have never used closures before but I can’t see anything about it that could cause bugs. Since JavaScript is very different from Java, closures may have some error-prone syntax. However, I see closures as a way to type less and to write more dynamic code.
for (var i = 0; i < array.length; i++)
{
someFunctionThatHasACallback(function()
{
doSomeCrap(array[i]);
});
}
That’s an oversimplified example, but basically doSomeCrap will get called on array[array.length-1] array.length times. That’s because the way a js closure works is that the most recent assignment to the value it finds will be used. The correct way of doing the above is binding i into the function as a parameter - thereby not using closures. The above is pretty obvious, but if you have a complicated group of callbacks that happen through like 3 different classes and two of them just happen to both define a variable of the same name, you can get the wrong variable being used.
Just pass around the variable you want, it’s so much better.
Oh well if there are multiple variables of the same name in different classes and the coder gets them confused, it is the coder’s fault 
I do understand your point but since I have yet to try to closures, I still assume I would be easily able to use them without being confused about the order of execution.
Sounds like I used Closures quite a bit in C# when it came to collection filtering and sorting. So can’t wait till its in Java.
I work with C# in my dayjob, and I for one will definitely welcome closures with open arms 
Miss my lambdas.
Relax they aren’t closures. They are lambda expressions and they are an entire different species. You won’t run into the javascript/closure issues you mentioned earlier.
Happy days are here again.
YAY! Java is getting a feature which is now common in most mainstream programming languages.
Hopefully we won’t have to wait 5 years for the next language feature.
Hi!
I disagree with a lot of people here. Java is going to become so complicated and remember what happened to C++ in the past… A modern language cannot get all “cool” features, choices have to be made and using several programming languages in a single project should not be a problem. Some languages are better to express of some kinds of things. If a single language tries to express at best anything, it can only become extremely complicated to use. Closures give a (contestable) comfort to some people but Java can live without it.
In my humble opinion, the syntax of Java should be frozen, the efforts should be concentrated on the APIs (repairing the existing APIs and adding new ones), the support of other languages on the same VM (not only scripting languages), the improvements of the deployment (applets and Java Web Start, plugin 3 with AWT-free fast launcher) and on the modularization (project JigSaw). I would prefer Oracle to help me to convince several Internet service providers to use Java in their ADSL TV boxes. We need Java everywhere, on consoles, on all smartphones including IPhones and Android (a DVM is not a real JVM).
Some C# programmers asked for closures in Java but I’m not sure that they are the people who use the most Java.
I agree with you even though I rarely use JavaScript. The “awesomeness” of this feature is not obvious for me.
I’ve managed 30 years without needing closures. Now they’re going to co-opt a few more ascii characters to do something that makes not a lot of sense and does even more trickery under the hood. Oh well, not much we can do about it.
Cas
I need to go and sit down and have a glass of water, I just agreed with Julien!
Cas
I agree too and also prefer that the java syntax be kept simple and basic (as some here like to call it as a ‘baby language’ :)). If they need all these extra things they should just pick up Scala and push it as an official jvm langauge. Scala has all the bells and whistles that one could hope for and is pretty compatible with normal Java too.
I think Scala is complex and inefficient. Something in between Java and Scala would be better. Kotlin sounds promising.
@gouessej - I’d generally agree with your list of priorities there and not adding stuff in for the sake of it. However, I’m coming around to this one, possibly for the same reason that Oracle did post-Sun, and in one word that is “concurrency”. It’s not that there are things impossible with Java’s current syntax, but the amount of boilerplate code that can be removed is sometimes staggering. Java has always included (for the time) good multi-threading support, and I guess this helps further that.
The crappy thing about all this concurrency support is that the whole premise it appears to be based on - that is, unified memory architectures and multiple cores - is kind of crap compared to the infinitely more sensible Transputery way of doing things. IMHO it’s going to set software engineering and hardware design back a decade 
Cas
What is the “cost” of closures on the “readability” of the source code? Do you have a precise example to illustrate your opinion? How are closures helpful in concurrency? The benefit of closures is very subjective, I can go on using anonymous classes containing a single method, complicating the syntax of the whole language can allow to avoid such boilerplate code but it can drive it more difficult to read.
It’s a matter of taste, I find closures worse than anonymous classes containing a single method and do you know the secret of very long projects? When I know I’m going to see my girlfriend, I’m happy because she’s pleasant and beautiful. It is exactly the same thing for my source code. I can work on the same project for years if I find the source code “pleasant and beautiful”. nsigma finds closures better than anonymous classes containing a single method; in his case, closures are the way to go.
Lol. I’m not surprised. I already knew that you agreed with me about this aspect. I’m even throwing AWT out of my game
I did have a precise example, I just can’t bloody find it now! : Essentially it’s to do with both fork/join (in 7) and also ParallelArray (in 8 I think). The example used 80% less code and was infinitely more understandable with closures. Parallelizing loop operations across data structures can benefit from closures, and seem much easier to understand without the boilerplate.
My absolute benchmark is less code and more legible - this example won me over! (and if I can ever find it again, I’ll post a link).
I write a lot of JavaScript, and closures are easily one of it’s best features. It is not that they will allow you to do anything new; it is that you can do the same in a more natural way. This means libraries will use closures more often, as they are much easier to wield then anonymous classes. Once your leveraging closures, there are lots of advantages.
The main one is that it allows libraries and frameworks to have more control over how they are used. It is very common to build a library, that manages some code, but has to be used in a specific way. As a result you can be expected to always call specific methods before performing certain tasks, or calling items in a specific order. Closures allow you to wrap up whatever task it is you are performing, then just hand it over, and have the library call it for you (at the right time).
For example asynchronously downloading multiple files, and running a task when they are all complete. Another example is being able to repopulate a cache, on the fly, when missing items are queried for. The task to generate those missing values can be stored inside the cache, using a closure. These are simpler to build if you can easily wrap up tasks to be passed in.
It can also allow you to build more efficient architectures. For example I once built a grid based data structure that partitioned sprites based on their class. It used custom data structures, but for simplicity, it was essentially a: Map<Integer, Map<Integer, Map<Class, List>>>. As you can imagine, iterating over that is not trivial, and a naive implementation requires using lots of iterator objects nested inside of each other. This iteration loop would build a list of Sprites to return, which would then be iterated over a second time by the caller. To improve this I built a version which used anonymous classes, and this allowed me to remove all of the iterator objects, the returned list, and the second bout of iteration. What is really important, is that is was simpler to optimize this using anonymous objects, then using a complex iterator solution. Closures make it more natural to build these solutions.
Finally writing a Swing UI is far too verbose. One of the issues is the large number of action listeners, and and closures would greatly reduce the amount of noise in your code.