Tim has posted 4 posts at DZone. View Full User Profile

Want Closures in Java 7? Vote!

10.23.2008
| 12861 views |
  • submit to reddit

Although Sun Bug Database is somewhat unpopular it is at least one way to influence the future of Java. I have read many articles on the web where developers demand for including closures in Java 7. It is really strange that the issue 5014235 "Closures support instead of annonymous inner classes" (submitted in March 2004) only has 24 votes!

Bug ID: 5014235
Votes 24

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5014235

Want closures in Java 7? Vote!

 Update: now (Oct, 24) the issue has already 105 votes and should appear on the list of "Top 25 RFE's" soon. I would like to thank everybody who voted and hope that our votes will be taken into account and that closures will make it into Java 7.

Published at DZone with permission of its author, Tim Lebedkov.

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

Comments

Milind Rao replied on Thu, 2008/10/30 - 2:19am

Exactly! Every example I have seen of what it will look like sucks. Generics has already hampered readability in Java. I'm not a fan of anonymous inner classes and hardly ever use them. And I'd like to see a better way to implement them, but closures isn't it.

Ricky Clarkson replied on Thu, 2008/10/30 - 3:19am in response to: Milind Rao

Can you tell me exactly what sucks about:

time() {

    your code here

}

J Szy replied on Thu, 2008/10/30 - 3:46am in response to: Jesper Nordenberg

[quote=jn45229]Yes, the conversion of closures to any interface is quite magical I agree.[/quote]

It goes further. Though it has not yet made it into the spec, the prototype includes method references which are of those functional types and are converted to closures.

There's more insanity lurking, as all of this is implemented by generics under the hood so you may expect all of those surprises and corner cases that generics have (500-page FAQ!), doubled.

[quote] However, that part is not required for a useful closure implementation in Java.[/quote]

The problem is, you may be able to implement closures typed nominatively but what you get is more or less anonymous classes. You might add some syntactic sugar there (which might or might not help), write access to the captured variables (which I believe is bad), non-local exits (horrible) and some other changes but you won't probably be able to get rid of the concept of the anonymous class. This is not necessarily bad, the language should evolve and although I don't agree with this specific path of evolution, it wouldn't be as dangerous.

Most closure proposals however don't really want Java to evolve, they seek revolution. That is, they propose a fundamental change to the way we program. It doesn't really matter if it is implemented mostly with existing Java features under the hood.

[quote] In fact, without it the BGGA implementation would be similar to the one in Scala. [/quote]

Correct me if I am wrong but I believe Scala is typed structurally.

Ricky Clarkson replied on Thu, 2008/10/30 - 4:23am in response to: J Szy

No, method references are not closures and cannot be converted to closures, as they cannot close over variables from the enclosing scope.  It would be like converting 3 to a closure.

As the translation rules to generics use are quite straightforward, I don't think there are a lot of corner cases and surprises lurking there.  One surprise for me in the early prototype implementations was that a closure taking an int and returning an int couldn't be used where a closure taking an Integer and returning an Integer was expected, but that seems to have been fixed.

Those things that you're complaining about (write access to captured variables, non-local exits) are actuallyuseful things in certain circumstances.  I keep using a time() { your code here } method as an example; it seems to fit here too.  Wrapping code in a closure shouldn't change its meaning (or prevent it from compiling).

I don't think it's true that the closure proposals don't want Java to evolve.  Please see Guy Steele's talk (which is on youtube or google video) titled Growing a Language.

"Correct me if I am wrong but I believe Scala is typed structurally."

Ok.  You're wrong.  Scala supports structural typing but with a specific syntax that is unrelated to its closure support.  Probably 99% of code doesn't use structural typing.

J Szy replied on Thu, 2008/10/30 - 5:02am in response to: Ricky Clarkson

[quote=rickyclarkson]No, method references are not closures and cannot be converted to closures, as they cannot close over variables from the enclosing scope.  It would be like converting 3 to a closure.[/quote]

Maybe not exactly close over as in the definition, but bound method references will keep the instance they're bound to alive even when it's inaccessible in any explicit way. I'd say little difference there is.

[quote]As the translation rules to generics use are quite straightforward, I don't think there are a lot of corner cases and surprises lurking there.[/quote]

I'm amazed every time I see someone able to write "generics" and "straightforward" in the same sentence.

I'd also bet that whoever approved the final Java 5 generics' spec, they had never imagined a 500-page FAQ.

[quote](write access to captured variables, non-local exits) are actuallyuseful things in certain circumstances.[/quote]

"goto" is actually useful in certain circumstances as well.

[quote]I don't think it's true that the closure proposals don't want Java to evolve.  Please see Guy Steele's talk (which is on youtube or google video) titled Growing a Language.[/quote]

A fundamental, one-shot change to the way people program can hardly be called evolution.

[quote]"Correct me if I am wrong but I believe Scala is typed structurally."

Ok.  You're wrong.  Scala supports structural typing but with a specific syntax that is unrelated to its closure support.  Probably 99% of code doesn't use structural typing.[/quote]

The Scala spec, section 3.5 describes an obvious structural typing discipline. Where am I wrong?

Jesper Nordenberg replied on Thu, 2008/10/30 - 8:40am in response to: J Szy

[quote=partyzant]

The Scala spec, section 3.5 describes an obvious structural typing discipline. Where am I wrong?

[/quote]

Which part in 3.5 are you refering to (it's a quite big section)? Structural typing in Scala means that you can define a type like "{ def x : Int }" and any type which has a member "def x : Int" conforms to this type. A closure or function object in Scala is always a subtype of scala.FunctionX and for example the type "X => Y" is merely an alias for scala.Function1[X, Y]. So, there's no structural typing involved in function objects. There's some magic (eta expansion) for automatically converting methods to function objects and there's a special underscore syntax for partial application (for example "_ + _" is short for "(x, y) => x + y"). Also in Scala a closure is allowed to modify variables in outer scopes.

All in all, closures work fine in Scala, and the language is much more suitable for functional programming than Java (even with closures). I suggest you try it out.

J Szy replied on Fri, 2008/10/31 - 3:09am in response to: Jesper Nordenberg

[quote=jn45229]A closure or function object in Scala is always a subtype of scala.FunctionX and for example the type "X => Y" is merely an alias for scala.Function1[X, Y]. So, there's no structural typing involved in function objects.[/quote]

To the contrary: it is impossible to define two function types that would have identical structure yet be incompatible. This is structural typing.

[quote]All in all, closures work fine in Scala, and the language is much more suitable for functional programming than Java (even with closures). I suggest you try it out.[/quote]

Playing with yet another language du jour is not my kind of fun, sorry. If it reaches a significant marketshare, I will try it out then.

Comment viewing options

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