Closures - Breaking the Deadlock

DZone 's Guide to

Closures - Breaking the Deadlock

· Java Zone ·
Free Resource
The decision threads about closures are currently in a situation that can best be described as a deadlock. BGGA has the most proponents, but also the biggest crowd against. FCS and CISE don't stir up too many anti-comments, but usually aren't the gurus' favorite proposal either since they lack new powers and doesn't represent the Java 3000 that many gurus want. This was the situation one year ago, and this is the situation today.

I do however think that we needsomethingfor Java 7. I'm pragmatic and think that Java will be nuked in the blogosphere if Java 7 comes with close to nothing exciting in the language department, even though it will have baked for as long as Tiger (summer 2009). Therefore, without further ado, I propose a two stage rocket for Java 7 and Java 8.

Stage 1

Lets ease up on the syntax and constraints for anonymous inner classes for Java 7. This should be done anyway since the number of anonymous inner classes will be much larger than actual closures in use for the foreseeable future.

Some snippets that illustrates what I mean, but any similar syntax will do as long as it is just an improvement of anonymous inner classes. No JVM changes and no "new" syntax. I can not stress this enough, the syntax is not what this article is about, the fact that stage 1 is easy to understand and easy to add to javac is. If you want more thought through syntax, think CICE without ARM and FCM without method pointers.

Interface with one method, no arguments:

    System.out.println("Later, Man..");
Interface with one method, x number of arguments:
actionPerformed(ActionEvent e) { e.doStuff();}

And the last improvement, which I think we are mature enough for now even though it was originally left out to keep complexity down. We need some way to use non-final local variables in an inner class:

volatile int myInt = 42; // Look, no final, and it IS editable...
SwingUtilities.invokeLater( { System.out.println("My int is now: " + myInt); } );

The use of volatile is something that I have thought about for a long time to solve the "final" problem. I just don't understand why it hasn't been added earlier to lift the restrictions on inner classes. It even makes it documented that the field is "volatile" and it has to do with threading, which is the original meaning on a field.

Stage 1 will add nothing new to the JVM, no "new" syntax and the old way will work. I think no one can really complain that this "isn't the Java way". IDEs that use javac for ASP processing will egen get this change for free.

Stage 2

Then, and only then, when we have tested this for a year or two in Java 7 can we really see how BGGA should be baked to get more power. Maybe we figure out that this is tasty and we need all the goods, or we think that we need only a little more power. Today this is only estimations. In two years at least we can say with certainty one way or the other.

The nice thing is that a closure proposal á la BGGA will not be hampered by this two stage rocket. It will probably not make it into Java 7 anyway because of time constraints and the current deadlock. Stage 1 is not competing and this rather small improvement of the language (since it is very easy to hack into javac) can be done in a speedy manner.

So, what do you think? Is this two stage rocket a sensible deadlock ejection? To me it sounds like the best approach and sort of a Middle Earth between Heaven and Hell (which one is wich is up to the reader to interpret). We get easier anonymous inner classes fast, and the correct power of BGGA in Java 8. I can see no real downside, except maybe for some lost pride in some camps. :)

Mikael Grev


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}