Comments on: Java Closures – The Fundamental Benefit

By: Howard Lovatt

Howard Lovatt — Sun, 29 Jun 2008 00:16:39 +0000

I think the different rules regarding different forms of returned can be overcome using named returns, as suggested in C3S. Neal Gafter has indicated in a reply to one of my blogs that he is considering named returns for BGGA. The idea of named returns is that return returns from the inner class/closure and if you want to return from the method enclosing the inner class.closure you say [methodName].return [value]opt;

The FCM proposal suggests that return returns from the closure except when the closure is used in a control structure, when it returns from the enclosing method.

I think that both named returns and the FCM proposal are superior to what is currently in BGGA, but as I said Neal is thinking of changing BGGA.

The C3S proposal adds no new semantics, it is just short syntax for inner classes. BGGA and FCM add a new construct the closure that is like an object but can’t inherit, can’t have fields, and its class has only one method. To get it to interact with objects it gets auto-boxed; but it can only be boxed into an interface with one method and once boxed there is no auto-unboxing. This autoboxing effectively introduces a second typing mechanism into Java, structural typing, thus complicating programs.

Personally I can see no advantage in the closure over the inner class, its less powerful than an object and needs auto-boxing and Java is an OO langage and I don’t think we should go adding further non-objects (primitives already cause problems).

By: WarpedJavaGuy

WarpedJavaGuy — Sat, 28 Jun 2008 02:35:45 +0000

Stephen, yes the BGGA semicolon rule got me.

Clearly then what is most desirable is a closure solution that does not introduce odd behavior and change existing semantics. Is CICE good enough? Is BGGA too drastic? Both C3S and BGGA change the semantics. Does FCM strike the right balance?

The debate over proposals will continue, but until we have closures in Java, the restructuring of code to eliminate redundancies will continue to result in unnecessary code which is itself redundant.

By: Stephen Colebourne

Stephen Colebourne — Sat, 28 Jun 2008 00:27:04 +0000

Your BGGA code example has a bug, and is the exact reason why BGGA closures are likely to be difficult to use in real coding. In case you haven’t figured it out, the println requires a trailing semicolon. Why? Because run() from Runnable returns void. Last-line-no-semicolon return only works if there is a non-void return type. And thats the kind of confusing set of rules we can do without in Java.
(Disclaimer – I’m co-author of FCM closures)

By: Howard Lovatt

Howard Lovatt — Sat, 28 Jun 2008 00:25:16 +0000

I am with Mikael. CICE, BGGA, C3S (http://www.artima.com/weblogs/viewpost.jsp?thread=182412), and FCM all give shorter syntax and write to local variables. The examples you have given only show that shorter syntax would be nice. There are serious drawbacks with closures (BGGA and FCM), they introduce a second typing system, they are like an object but not quite, and the meaning of return is changed. To allow the closures ‘to play’ with normal objects they get boxed, but there is no unboxing. This leads to strange behaviour, similar to the strange behaviour when primitives get boxed. Further, because there is no unboxing, other odd behaviour happens. Also closures cannot inherit and can only be boxed into interfaces, not classes. Java is first and foremost an OO language, lets keep it that way and not introduce something else that is not an object and requires boxing.

By: WarpedJavaGuy

WarpedJavaGuy — Thu, 26 Jun 2008 23:46:11 +0000

What Howard wrote was “Inner classes with short syntax and write ability to local variables do all this and more”. This is simply not true. The reason CICE makes sense is because it eliminates the boilerplate associated with anonymous inner classes.

My point in this post is to highlight the primary benefit that closures bring to the Java language. They introduce to Java a language construct that eliminates boilerplate and removes unnecessary redundancy.

By: Mikael Grev

Mikael Grev — Thu, 26 Jun 2008 21:25:33 +0000

You did not read what Howard wrote… He said “Inner classes with short syntax”. Like with CICE, the only closures proposal that makes sense this late in the Java cycle.

By: WarpedJavaGuy

WarpedJavaGuy — Thu, 26 Jun 2008 10:22:01 +0000

You cannot in the current Java language write anonymous inner classes without also writing boilerplate code. This is a necessary redundancy that cannot be eliminated. For example, the code snippet below contains boilerplate that is redundant and that you should not have to write.

new Thread(new Runnable() { 
  public void run() { 
    System.out.println("Anonymous Inner Class"); 
  } 
}).start();

..whereas closures eliminate the redundant boilerplate required above:

new Thread({ => 
  System.out.println("Closure") 
}).start();

As an aside, inner classes are a poor man's closure because they do not capture the enclosing environment in its entirety (that is: they do not capture variable names, the 'this' object, the referents of break, continue, return, etc..). Inner classes are definitely not closures. See closure definition.

By: Howard Lovatt

Howard Lovatt — Thu, 26 Jun 2008 07:53:08 +0000

Inner classes with short syntax and write ability to local variables do all this and more. Closures are a poor man’s inner class, see URL.