This post originated from an RSS feed registered with Java Buzz by Weiqi Gao. Original Post: Closures In Java Feed Title: Weiqi Gao's Weblog Feed URL: http://www.weiqigao.com/blog/rss.xml Feed Description: Sharing My Experience... Latest Java Buzz Posts Latest Java Buzz Posts by Weiqi Gao Latest Posts From Weiqi Gao's Weblog

(Via Pure Danger.)

Dario Laverde: Yesterday Alex Miller posted "Through the Java looking glass", which brought up some interesting points regarding the new Java 7 additions to the language wondering aloud if Java 7 "is going to succeed in creating an environment that still makes sense or whether it will be just the ugly step-child of these ideas which are better executed in their own environments".

Let me first acknowledge that I have not read any of the closure proposals. I have not played with the initial implementations by Neal Gafter, (although the closures.ztar has been sitting on my desktop for a while) or anybody else's initial implementations (are there anything else that are available?).

But I do have an opinion, or rather, a question, which I heard asked by Lauri Peterson, a fellow JUG steercom member, whenever something new and shiny is introduced:

Back in the days when local classes were added, one of the things that baffled many people is "Why do I have to declare a method parameter or a local variable final before I can use it in a local class?" And the answer given at the time was "to allow access to non-final method parameters and local variables would entail supporting lexical closures in the JVM."

So, before any new syntax are introduced, can we allow access to non-final method parameters and local variables in local classes? That way, we can say to the entrenched Java developer "You can still do everything you did, except now that you don't have to add a bunch of finals before your local classes will compile."

That's the closure I want. Can I have it?

Beyond that, I don't mind syntactic sugar that eliminates boilerplate code. But those should be introduced with care. First of all, make sure your syntactic sugar is not sour. Secondly, make sure your syntactic sugar doesn't cause cavities. And most importantly, don't introduce anything that would require a programmer to think some deep thoughts every time he codes with it, or worse, everytime he reads code with it.

Remember the original refrain that we used in our attempt to push C++ to the corner:

In C++, you need to approach

a = b + c;

with caution.

I just wish Java will never evolve in a way that will put itself on the receiving end of a similar comment.