Introducing closures is definitely not going to improve performance, because all the proposals are compile time translations only. What we are trying to achieve with closures is getting rid of boilerplate code which you dont have to write anyway with the latest IDEs. I agree it makes code more easier to write, but it is not like we cant live without it. Meanwhile the argument against closures is that it makes the language complex. Take C for instance. The widespread adoption is mainly due to its simplicity of syntax. With most of the recent languages adopting an interpreter based approach, why hasnt lisp or smalltalk made a comeback? Because they are complex. Complex to write, complex to maintain and complex to read. Dynamic languages are definitely not suitable for performance criticial applications, but closures doesnt make it better either. So if you still want to code in closures, we should adopt a dynamic language that already supports it and make it faster. No point in trying to make java complex.

That's not true. Dynamic languages, also called scripting languages, have a totally different purpose than statically typed languages. Scripting languages should be used when code needs to written fast, mainly by a single programmer. The focus is on programming speed, not on maintainability. Static languages are for projects that are better planned, often worked on by a group of programmers and that need to be maintained by different persons for a long time. You loose programming speed due to typing but produce more solid code due to type checking, that can be better maintained. To fit these two different purposes scripting languages and statically typed languages need different language features beside the typing story. For the quick and dirty approach it is perfect to have closures with all their potential side effects and runtime errors while it is very bad to have them in long living code. Therefore I like to use closures in Groovy for quick hacking but would hate to see them in Java. They add complexity and solve problems that Java shouldn't have.

It's interesting that the proportions have stayed very stable as word of mouth has spread - and the consistency of representation might suggest that this is a good indicator of how the general java market might respond. This puts considerable pressure on closures to deliver some effective early gains (APIs accepting closures would be a good start) and also keep the learning-curve as flat as possible so that the more complicated uses of closures are the exception instead of the rule.

When was the last time you were sitting around trying to figure how to solve something, and said, dang-it, if java only had closures... Apparently more often than you. I agree that the most complex uses of BGGA are complex to understand, but then these more complex cases are complex to express in java anyway - if these most complex cases prove to be common in your code-base you are probably abusing the facility and not writing the simplest solution to solve the problem... Abuse of language features in java is possible with boxing, anonymous classes, statics, initialisers - it's nothing new and poor language use by some developers is not a reason to restrict the growth of the language. That said, if it proves more complex than the concept it's expressing it is an issue and if it sets the knowledge bar too high, making acquiring adequate developer resources impossible java may shit in its own nest - forcing projects to other languages.

I don't think there would be any problem in adding literals to the other proposals, or in adding just the literals from FCM without the rest of it.

Freeze Java for a year, for two years, for a decade, forever?

It might help if you think of FCM as typesafe reflection - how can that be bad?

Leave closures to other languages that run on the JVM (Groovy, JRuby, etc.). Seems like another "me too" feature to the language that we don't need.

correct. "Closures" (aka OO function pointers) will do what Java's opponents have been trying for over a decade: they will kill the language, reduce its acceptance for new projects to a mere trickle, reducing it to a has been that's used only where it's too expensive to convert the source base to other languages. As it is 1.6 is coming close to that. Hardly anyone uses it seriously, rather sticking with 1.4 and 1.5. 1.7 will be worse, it will actively start people looking at alternatives, drive them away from Java for new development and force projects to consider the cost of porting to another environment as compared to the risk of sticking with a dying technology.

When I say I don't want closures. I meant I don't want any of the proposals in the main-line java language. If people want functional-language extentions to java put these in a different language. JavaF or something. The reason being if elaborate closures take over the language some of the community that have come to java to keep their solution simple will look for alternative platforms. One of the problems with the closure debate I have is some people want syntatic sugar for inner classes and others want binding of variables. Isn't it a bit late in the day to try and redefine java's scoping?

No I think most of the nay sayers mean exactly that. They really don't want any form of closure. Hey they may well not like anonymous inner classes either, but they are stuck with those.