I am a Java developer, designer, public speaker and a JAS 39 Gripen instructor fighter pilot. A somewhat unusual combination I guess, but I like challenges. I have created miglayout.com, migcalendar.com and Wing, a flight planning system used in several Air Forces. I find end user usability to be the most important part of a system and have therefore specialized in creating such applications. Mikael has posted 10 posts at DZone. View Full User Profile

Closures - Breaking the Deadlock

  • submit to reddit
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

Published at DZone with permission of its author, Mikael Grev.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Armin Ehrenreich replied on Mon, 2008/08/18 - 11:27am in response to: Mark Thornton

Obviously that solution isn't applicable to the fork/join use case. My understanding is that it was fork/join that initially prompted the closure proposals.

But as far as I know CICE would allow the fork/join framework and it would only be a little streamling of Java currently in use. It would perfectly fit to Java and there is no need to make simple things complicated.

If someone feels not busy enough, ther are many other programming languages to be learned. (Try if can master Scala for instance, its like an adventure game for computer scientists). But there is no need to morph Java into any other language.


Mark Thornton replied on Mon, 2008/08/18 - 11:35am in response to: Armin Ehrenreich

Nevertheless there is one new structure which is worth adding (in my opinion), and that is some sort 'with' that ensures that cleanup/close/unlock actions are called at the end of a block.

Jesse Kuhnert replied on Mon, 2008/08/18 - 12:41pm

This strategy sounds flawed and makes some incorrect assumptions.

There is no real need to "test" closures as we have lots of in-production languages using them already.  Sure, whatever jsr/jcp (whatever it is called) group is formed should definitely play with varying syntax definitions and try to make sure it's as universally appealing as possible - but the actual idea has already been tested thoroughly. 

 A two stage release of "closures" will - imho - cause more problems than good.  If you're going to introduce a change (even a cice-like change) - it is probably better to do it fully and at once.  Otherwise it may look weird/confusing to have real closures come out in java 8, or even worse - the fact that java7 would include watered down anonymous inner classes already would fuel all of the anti-closure peoples arguments of not introducing anymore change.  Ie killing BGGA.  

Java 8 will be too little too late. James/the others at Sun seem to know what the right thing to do is already,  let's just cross our fingers and hope Sun will rally behind them and make it happen.

Alex(JAlexoid) ... replied on Mon, 2008/08/18 - 3:32pm in response to: Brian Sayatovic

[quote=Brian Sayatovic]So you can have a snippet of logic that is dettached from any type definition and anonymously pass it around?[/quote]

A: It may or may not be detached.
B:It may have a very precise type definition.
C: "no semantic definition" - Semantic definition? Does a WorkManager class with only work method add any semantic definition to that class?
D: "anomymous snippets of logic" is NOT what a functional language is all about,assembler would be better.

Howard Lovatt replied on Tue, 2008/08/19 - 6:55pm in response to: Armin Ehrenreich


I am not against shorter syntax for inner classes. Comparing shorter syntax inner classes with closures, I don't see that the API style would change that much. Even with long syntax for inner classes thre are plenty of API's that you pass a piece of code to, e.g. Runnable and Callable.

Howard Lovatt replied on Tue, 2008/08/19 - 7:01pm in response to: Alex(JAlexoid) Panzin


 The BGGA and FCM proposal do introduce a closure with different semantics than a normal object and to interact with normal objects the closure gets auto boxed. I think this is a bad idea, give them the same semantics as an object, Java is after all primarily an OO language. The argument for different semantics appears to boil down to that's what procedural languages do and also what Smalltalk did, there doesn't seem to be a use case that supports the different semantics as superior. If anyone has a good use case for the different semantics of the BGGA and FCM closures it would be interesting to see it.

Jeroen Wenting replied on Fri, 2008/09/05 - 3:04am in response to: Mark Thornton


It sounds like throwing a thunk of code in a quick and dirty way at another class or thread. I'm glad Java makes it difficult and hope it will continue to do so.


Do you have any idea of experience of the kind of code you are dismissing out of hand? In particular do you know anything about the fork/join frame work and the fine grained parallelisation enabled by the Parallel*Array classes?


 Bit late, but yes.
I've cowritten a large message broker system in C that would interface between a mainframe application and 3rd party applications in sales terminals.

The central feature of the thing was a web of function pointers, different parts of each message causing the exact sequence of function pointers to be executed to be built up.
Interesting philosophical exercise, and it even worked, but it was far from transparent (extremely flexible though, to add a new mainframe call you just had to define a new function and pointers to it).
Would have been so much simpler using Java with some interface to derive the functionality from and a thin layer of reflection to initialise the required objects.
Not that Java existed for that platform at the time (and 1.0 was hardly suitable for production level performance on servers anyway).

And that's just one of several projects.

Hard as hell to figure out what's going on where. The paper graphs of the application logic were often larger than the logic itself.
Even harder to debug and trace problems (and you WILL have problems).

To add anything like it to a programming platform that has a perfectly good alternative to function pointers (as Java does) is insanity.

Kookee Gacho replied on Mon, 2012/06/18 - 5:12am

Closure is not permanent. New social groups may form and reintroduce interpretative flexibility, causing a new round of debate or conflict about a technology. (For instance, in the 1890s automobiles were seen as the "green" alternative, a cleaner environmentally-friendly technology, to horse-powered vehicles.-Dr. Marla Ahlgrimm

Kookee Gacho replied on Mon, 2012/06/25 - 7:43am

A simple computer-based example is as follows. Suppose a computer has three CD drives and three processes. Each of the three processes holds one of the drives.-Marla Ahlgrimm

Liezel Jandayan replied on Wed, 2013/01/23 - 7:00am

 You’ll especially notice the larger article headlines on the Zone homepages. The goal here? Letting you scan the whole Zone feed more quickly, making it easier to find stories particularly interesting to you.-Danielle Aykroyd

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.