Extending generics to primitives would also substantially reduce the number of interfaces required by the fork join proposal. Most of those 80 interfaces are just the result of enumerating different combinations of object and primitive parameters. As performance is crucial to fork/join ( you wouldn't use it at all if performance didn't matter), it isn't possible to eliminate the use of primitives.

The decision should be made NOW to scrap the entire "closures" idiocy completely. There's no need for function pointers (and that's what they essentially are) in Java. All they do is make the language syntax far more obscure and obfuscated, which serves noone except for stroking the vanity of the person(s) whose proposal gets implemented for a while (until the negative consequences of the adapting of their idea become apparent to all that is, after that they'll just have notoriety). Maybe it's time to hand over the language spec to the ISO/ECMA, at least they spend decades debating such decisions, making them both well thought out and late enough that my career would be over before they ever make it into the mainstream, rather than making them based on a Me2! mentality as is the case with everything Sun and the JCP are doing these days.

Don't you think that there's some level of "pot calling kettle" with all this fanboy talk? I mean those against the idea are surely anti-closure fanboys so why don't we drop the name calling and insults and actually say something of meaning and substance about the issue? Oh and anybody who wants to stop programming in Java if it gains closures I'm sure are more than welcome in .NET but I'd best warn you the closures are already there. IMHO, and that's all it is, a large number of people don't want closures for two big reasons: seemingly complex syntax, and being irritated by the generics introduction. To address the later first; if you feel that one feature of the language (which you are not obliged to use just turn off the warnings) that doesn't work for you is a good enough reason to spurn any further features of Java then so be it. The same was said about many of the PHP5 features but its still got a strong userbase. Nobody says you have to use closures if they're introduced have they? Say you don't like the Sun implementations of the Collections interfaces, you'd use something else right? Like the Apache commons stuff. Coming back to the syntax; if you don't understand it its probably because you've not read it properly. Sorry but its true, the syntax is nothing new with respect to lambda expressions and even bears a strong resemblence to C function pointer syntax. If you read, say, Neal Gafter's articles on the BGGA implementation I'd be very surprised if you couldn't then understand it AND more importantly why its formatted that way. Again IMHO if closures are to be included the debate about their implementation is either simple syntactic sugar for anonymous inner-classes OR a more flexible and powerful (should you wish to lever it) feature? I think if it were possible I'd like to see, as others have said, a longer period before the J7 release and a good amount of bug fixing and optimising in the current release.

How about we just create a JSR for getting C# running on the JVM? They have properties, events closures, no bloody checked exceptions and then Sun can have as much fun with JavaFX and other derailments as they want. :)

I can't really answer this (as the co-author of FCM closures). The problems involved are complex, and the practicalities of finding a suitable solution equally so. "Closures" has also come to mean many things in the debate, from simpler inner classes right up to full-featured Scala-like constructs. I should also emphasise that the debate isn't really about the syntax, but the semantics. Do last-line-no-semicolon return of values, and non-local returns have a place in Java? Is the extra power justified? My opinion is that the debate needs at least another 2-3 years of expert examination if the right answer is to be reached. If Java 7 will wait, then so be it. Personally, I would have preferred to have seen a Java 7 out this year with no language changes, followed by a Java 8 with such changes in about 2010. But unfortunately, Sun have taken their eye off the ball with the JavaFX misadventure.

As much as I would like to see properties in Java, there is no JSR or even proposal which has enough community interest, so it is very unlikely. And that's a shame, because all the new binding and validation stuff is using Strings. As for closures BGGA syntax is only scary in the beginning, and it's easy to get used to. Closures come from functional programming and the syntax follows FP style - yes, it is not like anything in Java today because it's a new paradigm, so what? One thing I would want to be taken in account is this: hopefully Sun has not given up on generics reification in the future, and that would allow more type inference, how (or whether) would it affect the closure syntax? From my very modest understanding, BGGA would greatly benefit from reification/type inference, making the piece that spooks many Javans today ( => ) optional. But some real language expert should make sure the syntax is "forward compatible" with reified generics. So I say, give us BGGA closures, and those who are scared of the syntax will not use it until it is simplified in a later version. But bold libraries providers will benefit from it ASAP.

As much as I would like to see properties in Java, there is no JSR or even proposal which has enough community interest, so it is very unlikely. And that's a shame, because all the new binding and validation stuff is using Strings. As for closures BGGA syntax is only scary in the beginning, and it's easy to get used to. Closures come from functional programming and the syntax follows FP style - yes, it is not like anything in Java today because it's a new paradigm, so what? One thing I would want to be taken in account is this: hopefully Sun has not given up on generics reification in the future, and that would allow more type inference, how (or whether) would it affect the closure syntax? From my very modest understanding, BGGA would greatly benefit from reification/type inference, making the piece that spooks many Javans today ( => ) optional. But some real language expert should make sure the syntax is "forward compatible" with reified generics. So I say, give us BGGA closures, and those who are scared of the syntax will not use it until it is simplified in a later version. But bold libraries providers will benefit from it ASAP.

+1 for properties If my understanding is right, it will allow use easy binding, which is the main new feature of JavaFX Script (besides the other features :) )

I think Java 7 should be shipped in 2 or three years time. Priority should be set on quality not on new features. Take your time to think about each and every language change included. Meanwhile Java 6 should see many bugfix releases. Quality is much more important than features !!!

It's a new and exciting way of looking at many old and odd problems. And don't forget properties as first-class citizens ;-)

Please, also ship other libraries like java.util.concurrent with closures functionality.

Is now the time to debate syntax? People were getting a lot of flack for debating syntax when this was all just proposals. Now we have prototypes and "feature complete" implementations, is this the time? I find BGGA to be a very confusing syntax. It does a lot of things in an unintuitive way for no other reason then to just to be different. In java if something takes parameters and returns a value it's written like this: int valueOf(String s){ ... }; In BGGA a closure that takes the same signature is. {int => String s ....} It's the same signature so why isn't it even something close to the same syntax? in FCM you write the same thing like this: #int(String s){ ... } Other then the # sign it's exactly like what you would do if writing a method. Whats with the "last line no semi-color means return" semantic? How is that expressive? Why can't I return early? Why introduce a place in the code where NOT putting a semi colon at the end of the line means something? I'm sure the answer is because then you'd have to use return keyword. Well I've used languages with no return keyword. VB 6 had no return keyword and you had to play all kinds of games to return the value you really wanted and break out of loops and things like that when things got complicated. BGGA is not the answer, it's just the one that's gotten the most attention. FCM+JCA is virtually the same functionality in a more Java-like package plus useful extras like field and constructor literals.

The experience from generics show that a rushed process gives us too much complexity and too little power. Closures, done right, has the potential of extending the life span of Java with another fifteen good years. Done wrong, the complexity could be the hair that broke the camel's back. Rushing now means BGGA, which hardly anyone understands.