Closures In Java
(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 approacha = 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.
[Update] Several things:
- There is a lengthy debate on this topic at the JavaLobby.
- Many people posted their opinions in the past couple of days. I find myself agreeing with almost everything Tim Bray said.
Tim Bray: But if they’re going into Java, they need to earn their way and be field-tested in the open-source ecosystem first.
Re: Closures In Java
Re: Closures In Java
Hmm, so I've accidentally aligned myself with Bob Lee, Doug Lee and Josh Bloch, and potentially against Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé. That's not a confortable position to be in.
It is at times like this that I wish there were more than one widely used Java compilers owned and steered by different governing bodies. That way each proposal can find support with one or more Java compilers and be implemented as proprietary extensions. The features will then get used in the field. And a few years from the initial shipment, a standard committee can be convened to hammer out whether the feature should be standardized and what the standard should be.