Closures are now officially announced as probably becoming part of the Java language. Here are a few links about that:
If one reads the comments of the previously mentioned blogs one gets a quite polarized view. Some people vote enthusiasticly for it and others are strongly against it. What frightens me a bit is the opinion of the initiators who say "Either people understand closures or they don't like it". Since I did not find a proof for that I believe that the authors take the critics somewhat easy. Or, to take it less kindly: the authors have no striking arguments to the critics, so they blame the criticizers to not understand the thing.
I must admit that I have very mixed feelings about introducing closures into Java. I did not work with a language with full support for closures yet (if you do not count C as one of them; but when working with it I did not use function pointers widely). So I could as well be blamed as someone who do not understand closures. The following may be read in the light of that.
Amongst my major concerns are readability and maintainability. The former can be due to lack of experience although I work with anonymous classes quite a bit (but I do not like them very much and try to avoid them as far as I can for the sake of readability). On the other hand, what I love with Java is the consequent implemntation of the famous Einstein words "Make it as simple as possible, but no simpler". As is pointed out eg. in "The psychology of computer programming" by Gerald M. Weinberg, the simplicity of a language is a key for its successful use. I do not think that additional language constructs as the proposed ones are adding simplicity and clarity, especially if the plans come true that exisitng keywords depend in their meaning on the context. Adding new keywords instead won't simplify the language either. The latter objection might be more serious and is not completely decoupled from the former. There are two problems here: the first is the defining context which can be manipulated. This opens the possibility to have context on local variables which in my opinion should be restricted to instance variables. Lets assume having two closures defined in the same context. In that case the outcome of each closure call can depend on the outcome of another closure call depending on the state of the local variables in the context. Of course the same effect can be achieved by exisitng language constructs. But one has to use types explicitly for that which makes the context more obvious. Another obstacle to me seems to be the quite complicated constructs of the closure return statement, especially non-local transfer. When calling a method with a closure as parameter, the closure might be preserved for later use within the instance called. This may introduce new points of failure or hard to analyze code. Additionally there may be problems with serialization.
As a last point for today, as far as I understand what I read so far, one of the most valuable uses of closures is in conjunction with collections. For that, the Java collections must be reviewed, adding new interfaces to them.
