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

Want Closures in Java 7? Vote!

10.23.2008
| 12922 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

Otengi Miloskov replied on Thu, 2008/10/23 - 12:46pm in response to: Ricky Clarkson

Blocks (Aka Closure) for C and Objective-C  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html

I dont have in hand the ISO standarization committee paper that they are describing to include in the next C revision Closures to ISO C thanks also to the efforts of this people and Apple because they want to include closures to Objective-C and that means also to C.

Sorry if I meant already C have closures my mistake.

Serge Bureau replied on Thu, 2008/10/23 - 12:47pm in response to: Ricky Clarkson

[quote=rickyclarkson]

Only the first part of that was about C.  "C doesn't have closures".  I'm not sure how writing a complex system in C would make it gain or lose closures.  I really don't understand why you said that!

[/quote]

 

Because the added features of languages are to allow better abstraction and so solve more complex problems. Closures would make many constructs much easier in Java than what is now allowed, so it allows even greater abstraction without complex syntax, so it is definitely a gain .

 

C misses a lot of constructs and would not even be considered on lot.s of projects . I see you will answer that the same is true of Java, but the range of applications is quite different.

J Szy replied on Thu, 2008/10/23 - 1:27pm in response to: Otengi Miloskov

[quote=OtengiM]It is really easy, you dont like closures don't use it, but not because some people doesnt want closures another we have to pay the price and use an outdated language.[/quote]

If it only were that easy, but the fact is that if closures get included then most people will be forced to use them, one way or another. Like generics, but more; you can ignore generics and use new APIs like it's 1999 but closures won't give you that option.

[quote]As I said if Java doesnt keep it up it will loose the rest of infrastructure of users maybe they will go to C#, Ruby, PHP etc and where your outdate language will be?, Isolated in a server as cobol language it is now.[/quote]

Get real. No one, except maybe some blog weenies, will switch to any other language because of closures. Ever heard of a language called Perl? It's been heavily criticized for the last 15 years because of its "write-only" "executable line noise" syntax. Its development has been pretty stalled since 2002 and the last major version was released in 1994. Looks like a good description of a dead language, doesn't it? Yet Perl is about three times as popular as the clean, readable, "executable pseudocode" Python, at least among the employers.

Java is now far more successful than Perl ever was and it will continue to be successful for years, with or without closures.

C# was successful before it had closures and there's hardly any evidence that the closures were of any competitive advantage to it.

[quote]Programming languages are tools not religions. [/quote]

Yes, and Java is the best one so far. It has earned its position without closures and closures will not help it to keep it.

There may be valid reasons to introduce closures but "if we don't people will switch away" is not one of them.

Lieven Doclo replied on Thu, 2008/10/23 - 4:30pm

Although I wasn't going to comment anymore... My point exactly. I have no doubt closures can be great for certain uses, and believe me, I'll be using them if they are in the spec. But a language that's no good without closures won't be good with it. And the same goes for the opposite.

Rewriting for-each loops using closures... could be fun, but I'd still like the option of choosing my style of coding. Like partyzant said, if they get in the language, you'll be confronted with them at one point, be it in your own code, the code of a colleague who's closure-happy or library dependencies that use them. Saying 'if you don't like them, don't use them' sound great, but when you're debugging code and happen to stumble upon some code that uses closures, you'll have no choice. And that is something I don't like.

I'm neutral towards closures, with a tendency for rejection, just because the subject is getting somewhat religious... The only thing I can say, after the talk of Joshua Bloch last year on Javapolis on closures, I exited the room with a mixed feeling. And I'm sure it'll stay, no mather the fact closures get included or not.

The talk can be found here: http://www.parleys.com/display/PARLEYS/Home#talk=5210267;slide=1;title=The%20Closures%20Controversy

 

Martin Wildam replied on Fri, 2008/10/24 - 3:30am in response to: Otengi Miloskov

[quote=OtengiM]Java need closures, Already all the languages include it, Even for god sake PHP 5.3 have closures.

C#,VB.net, Python,C, C++, Ruby, PHP, Haskell, Smalltalk, Lisp etc etc have closures.[/quote]

Only because everybody does something does not necessarily means that it is good!

Exceptions is just one example - see http://www.joelonsoftware.com/items/2003/10/13.html for instance.

I think too many possibilities to code something in a dirty manner only invites people doing too much of dirty programming or at least difficults debugging (I am thinking of aspect oriented programming here also).

I would say that it is much more important to improve speed for instance.

Jess Holle replied on Fri, 2008/10/24 - 5:18am in response to: Otengi Miloskov

It's clearly not as easy as "if you dont like closures don't use it".

If you're in a large development organization developers will use it and will use it in both appropriate and inappropriate fashions and you will end up having to understand and maintain both bodies of code -- as will inexperienced developers.

Closures are some pretty cool stuff, but in environments like this cool is not always cool.

[As already noted I'm generally in favor of closures -- but I am realistic about downsides.]

Martin Wildam replied on Fri, 2008/10/24 - 6:53am in response to: Jess Holle

I further think that a lot of such "gimmicks" are often used as workarounds about bad software design.

J Szy replied on Fri, 2008/10/24 - 3:01pm

[quote]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[/quote]

I wonder whether this proposal will eventually have more votes than operator overloading *evil grin*

Otengi Miloskov replied on Sat, 2008/10/25 - 10:58am

So the people that are against of new sugar or features as Closures are afraid or are just trolling?, I can not understand someone that use every day Java cant accept new features to the language that can make it less verbose and less repetitive and a pleasure to use everyday.

In all languages everybody can make ugly code but I would prefer a more expressive language to work everyday than one that is outdated and verbose and repetitive.

People, don't let Java fall in the dust, Also I want to propose to support more the Java OpenSource because we don't know what could happen to SUN on this financial crisis.

I want to see Java live and well.

 

Lieven Doclo replied on Sat, 2008/10/25 - 1:29pm in response to: Otengi Miloskov

Trollling?? I use Java every day, and I want to believe I'm quite good at programming in Java. I can and will accept new language features, but only when there's completely no doubt about its usefullness by everyone.

Afraid? Only that a few will enforce an idea on others which will ultimately harm the language itself. I'm convinced Java can benefit from closures, but some proposals are just so plain complicated that you'll alienate a lot of the users. 

 ... new features to the language that can make it less verbose and less repetitive and a pleasure to use everyday.

Less verbose... yes. Less repetitive... what's the difference with the situation before?? A pleasure to use... perhaps to you, but you're not the only Java developer on this earth.  There are others that evangelize operator overloading in Java, and are as convinced as you that it's needed. Are they correct by default then?

In all languages everybody can make ugly code but I would prefer a more expressive language to work everyday than one that is outdated and verbose and repetitive.

Why do people keep telling Java is outdated? If that's the case, congratulations, you're an outdated programmer and should've been programming .NET when you had the chance. Just because it doesn't have closures, it doesn't mean Java's outdated. Give me a break.

Proposals like BGGA will more likely increase the chance for ugly code than actually decrease it. Please, take a look at the talk of Joshua Bloch on closures (link is posted in an above comment) and then come back on whether it's easier to write good looking Java code with closures.

Liam Knox replied on Sat, 2008/10/25 - 7:12pm

Personally I would like to see some form of closure/control abstraction, but understand the arguments for and against the current proposals.  However I really was taken a back by such s braindead evaluation of this request by Suns engineer Sigh, and have commented such.

I hope we get something soon. 

Martin Wildam replied on Sun, 2008/10/26 - 5:18pm in response to: Otengi Miloskov

[quote=OtengiM]I can not understand someone that use every day Java cant accept new features to the language that can make it less verbose and less repetitive and a pleasure to use everyday.[/quote]

It depends on the price. If the support of Closures would affect performance for instance then I would think twice. Writing some additional lines of code may be less dangerous. A system that is too complex leads to increased probability of arising problems. - So as I mentioned: It depends on the price that we pay for that feature...

[quote=OtengiM]In all languages everybody can make ugly code but I would prefer a more expressive language to work everyday than one that is outdated and verbose and repetitive.[/quote]

Yes, you can write ugly code in all languages, but some languages make it easier to create ugly code (just thinking of perl ;-) ).

Slava Imeshev replied on Mon, 2008/10/27 - 3:24pm

To my taste, Java has reached it's top as a language with the release of 1.5. All is left is to write good software with it. Closures wouldn't add much. Those who do great programs would continue doing it. Those who do crappy software would get a handle to make it even worse. Die Closures, die!

 

Regards,

Slava Imeshev

 

 

Dzmitry Churbanau replied on Mon, 2008/10/27 - 7:41pm

I can not understand, why does anybody want closures? You can not do smth without it? Yes, may be you need to spend on 10-20 seconds more, but your code will be clear, understandable and so on.

I just watched this: http://www.parleys.com/display/PARLEYS/Home#talk=5210267;slide=1;title=The%20Closures%20Controversy

doclolieven, thanks for the link. And after watching i became more confident that java DOESN'T NEED IT.

It is not Java style. It is not Java life. I wish i can vote against this proposal.

Jeroen Wenting replied on Tue, 2008/10/28 - 7:35am

Closures are function pointers, period.

They may be more fancy because they're "OO" and therefore "kewl", but they're still function pointers.

We, the people, don't want them. Only a few guys in their ivory towers of academia who want their name on a JSR want them, and those fools who believe in the Me2! style of deciding what "features" the language should get. The only consistency in arguments for them are a few very obscure cases where they'd save a few characters of coding over using an anonymous inner class while making a total mess of the syntax, and kids claiming that "Java is dead because it doesn't have closures and Ruby does".

I've been exploring other technologies to flee to when (not if, like Obama inevitably stealing the presidential election through fraud I don't see how the Me2! crowd can fail to win the day in the JCP with their arguments that Java needs closures BECAUSE Ruby has them) this abomination gets adopted.

C++ looks interesting. Even Cobol has its charms (and is certain to keep me occupied until retirement).

Ricky Clarkson replied on Tue, 2008/10/28 - 8:45am

Closures are not function pointers.  To give an example, C has no closures, but C has function pointers.

Closures are not remotely OO.

Who in academia is involved in closures?

If you will run from closures, I might also suggest you add FORTRAN and dynamically scoped versions of lisp (such as elisp) to your reportoire.  I think this is a problem of yours rather than of languages though.

Serge Bureau replied on Tue, 2008/10/28 - 2:56pm in response to: Slava Imeshev

[quote=imeshev]

To my taste, Java has reached it's top as a language with the release of 1.5. All is left is to write good software with it. Closures wouldn't add much. Those who do great programs would continue doing it. Those who do crappy software would get a handle to make it even worse. Die Closures, die!

 

Regards,

Slava Imeshev

 

 

[/quote]

It seems to me you do not really understand closures.

 

Just for fun, take a look at ObjectiveC, ObjectiveC is basically C plus closures, and nobody would say it did not gain from it ?

So do not deny improvements based on your narrow views.

Slava Imeshev replied on Tue, 2008/10/28 - 4:39pm

Serge,

Jeroen Wenting two posts above just replied about me2 mentality, and I totally agree with him. I don't want closures. Some crappy obscure languages that have them don't mean that I have to want them. Java is perfect as it is. Just leave it alone, please.

More generally speaking, someone needed closures in Java has clearly skipped OOA/D course (if ever attended). No hire.

 

Slava

 

 

Jeroen Wenting replied on Wed, 2008/10/29 - 1:43am in response to: Ricky Clarkson

[quote=rickyclarkson]

Closures are not function pointers.  To give an example, C has no closures, but C has function pointers.

Closures are not remotely OO.

[/quote]

Closures serve the exact same function that function pointers do, allowing the passing of executable code as method arguments.
They're indeed not syntactically identical, but they are functionally identical enough to class them as identical.

They're not OO in their intention indeed, they are an attempt to introduce non-OO paradigms into an OO world while making it look like they're OO.

Interesting how you claim that anyone not liking closures should stick to Fortran or Lisp. I assume those are the 2 languages you like least?

Closures are a problem, or rather the people who want them are the problem, especially those who want them while fully understanding that they go counter to OO principles yet want them in an OO language.
If you like them so much, stick to Ruby (and yes, I do like Ruby and think closures have a place there and in other languages designed from the ground up to support them. I don't however think they have a place in Java).

Jeroen Wenting replied on Wed, 2008/10/29 - 1:46am in response to: Serge Bureau

[quote=SergeBureau]

It seems to me you do not really understand closures.

[/quote]

Interesting how you translate "I don't want closures in Java" with an almost automatic "in that case you don't understand closures"...
It seems the only thing the closure "fanboyz" can do is mudslinging to discredit their opponents.

Jesper Nordenberg replied on Wed, 2008/10/29 - 3:34am in response to: Jeroen Wenting

[quote=jwenting]

Closures serve the exact same function that function pointers do, allowing the passing of executable code as method arguments.
They're indeed not syntactically identical, but they are functionally identical enough to class them as identical.

[/quote] 

You are only partially correct. A closure can be seen as a function pointer + data which is implicitly passed as argument to the function when it's called.

[quote=jwenting]

They're not OO in their intention indeed, they are an attempt to introduce non-OO paradigms into an OO world while making it look like they're OO.

[/quote]

In what way are closures non-OO? You do realize that many OO languages has closures (including Smalltalk which was one of the first popular ones and from which Java has borrowed many ideas)? They intergrate quite well into a OO language like Java by simply encoding them as subtypes of a Function interface. 

J Szy replied on Wed, 2008/10/29 - 4:01am in response to: Jesper Nordenberg

[quote=jn45229]A closure can be seen as a function pointer + data which is implicitly passed as argument to the function when it's called.[/quote]

Indeed. This is why closures should never be allowed into Java. There is already enough trouble with final variable capture by the anonymous classes (and common antipattern of wrapping variables into one-element arrays); arguments should be only passed explicitly, never captured.

[quote]In what way are closures non-OO? You do realize that many OO languages has closures (including Smalltalk which was one of the first popular ones and from which Java has borrowed many ideas)? They intergrate quite well into a OO language like Java by simply encoding them as subtypes of a Function interface.[/quote]

This is not just an OO issue, it is also a typing issue. Smalltalk is typed structurally, Java is not. Closures (function types), both of BGGA and FCM are typed structurally.  They just don't fit. (BGGA closures also use generics under the hood, imagine how long will be the Generic&Closures FAQ once they are included.)

Java has indeed borrowed many ideas from Smalltalk, but the trick is to take what's good and leave the rest. Closures and structural typing should both be left out.

Jesper Nordenberg replied on Wed, 2008/10/29 - 4:37am in response to: J Szy

[quote=partyzant]

Indeed. This is why closures should never be allowed into Java. There is already enough trouble with final variable capture by the anonymous classes (and common antipattern of wrapping variables into one-element arrays); arguments should be only passed explicitly, never captured.

[/quote]

If you allow modification of outer variables in the closure, yes, it would require some changes to handling of captured variable access, but this has already been implemented in languages like Scala.

[quote=partyzant]

This is not just an OO issue, it is also a typing issue. Smalltalk is typed structurally, Java is not. Closures (function types), both of BGGA and FCM are typed structurally.  They just don't fit. (BGGA closures also use generics under the hood, imagine how long will be the Generic&Closures FAQ once they are included.)

[/quote]

Closures can definitely be implemented without structural typing, just look at C# or Scala for example. I think you're incorrect about BGGA as well, it doesn't use structural typing it generates function interfaces with pre-defined fully qualified names. Functions of the same type implement the same interface.

Note that I'm not advocating for or against adding closures to Java, but I do like lambda expressions (and use them quite often) in C#. When it comes to programming for the JVM I find Scala a superior alternative to Java.

J Szy replied on Wed, 2008/10/29 - 6:10am in response to: Jesper Nordenberg

[quote=jn45229]If you allow modification of outer variables in the closure, yes, it would require some changes to handling of captured variable access, but this has already been implemented in languages like Scala.[/quote]

I didn't write it was hard to implement.

The problem is that capturing variables instead of passing them explicitly makes the code less readable and harder to follow. This may be not very much an issue when a variable is captured by a simple lambda but when it is captured by a large block and allowed to be modified concurrently, it is a serious problem.

[quote]Closures can definitely be implemented without structural typing[/quote]

A closure is a function allowed to close over (capture) free variables. Anonymous classes' methods are closures, so this is quite obvious.

Yet, I didn't write whether it is possible or not, but that both BGGA and FCM define function types as structural, while the Java language is typed nominatively. This means that among function types both equivalence and subtype relationship are determined by the function types' structure (in this case types of the values returned, number and types of parameters and relations among the exceptions thrown) and not by explicit declarations as it is in what Java is now.

[quote]I think you're incorrect about BGGA as well, it doesn't use structural typing it generates function interfaces with pre-defined fully qualified names.[/quote]

Have you read their spec? You should.

Jesper Nordenberg replied on Wed, 2008/10/29 - 7:09am in response to: J Szy

[quote=partyzant]

The problem is that capturing variables instead of passing them explicitly makes the code less readable and harder to follow. This may be not very much an issue when a variable is captured by a simple lambda but when it is captured by a large block and allowed to be modified concurrently, it is a serious problem.

[/quote]

Concurrency is always a problem. I fail to see how this problem is magnified by adding closures. On the contrary, using closures can simplify many useful patterns that makes concurrent programming easier.

[quote=partyzant]

A closure is a function allowed to close over (capture) free variables. Anonymous classes' methods are closures, so this is quite obvious.

Yet, I didn't write whether it is possible or not, but that both BGGA and FCM define function types as structural, while the Java language is typed nominatively. This means that among function types both equivalence and subtype relationship are determined by the function types' structure (in this case types of the values returned, number and types of parameters and relations among the exceptions thrown) and not by explicit declarations as it is in what Java is now.

[quote]I think you're incorrect about BGGA as well, it doesn't use structural typing it generates function interfaces with pre-defined fully qualified names.[/quote]

Have you read their spec? You should.

[/quote]

Actually I re-read some of it just before replying. Here's an example copied from the spec:

{int,String=>Number throws IOException} xyzzy;

is translated into

interface Function1<R,A2,throws E> { // system-generated
R invoke(int x1, A2 x2) throws E;
}
Function1<? extends Number,? super String,? extends IOException> xyzzy;

So it seems function types are merely aliases for normal Java types, there's no structural typing involved. Actually this is very similar to what is implemented in Scala where the type "X => Y" is merely an alias for "Function1[X, Y]".

There's also automatic conversion of a closure literal to any matching interface type, but again that has nothing to do with structural typing.

J Szy replied on Wed, 2008/10/29 - 7:41am in response to: Jesper Nordenberg

[quote=jn45229]Concurrency is always a problem. I fail to see how this problem is magnified by adding closures. On the contrary, using closures can simplify many useful patterns that makes concurrent programming easier.[/quote]

Allowing local variables to be modified concurrently is a problem. Languages that are designed for concurrent programming encourage, or even enforce immutability. 

This is not a problem of the closures per se, but of allowing locals to be modified by the code closing over. It would be just as bad if the anonymous classes were to be allowed this.

[quote]Actually I re-read some of it just before replying. Here's an example copied from the spec:[/quote]

My, it's explicitly written in the spec:

[quote]A function type { T0 ... Tn => Tr throws E0, ... Em } is a subtype of function type { U0 ... Ul => Ur throws X0, ... Xk } iff all of the following hold:

  • Either
    • Tr is the same as Ur or
    • Both are reference types and Tr is a subtype of Ur;
  • n is equal to l;
  • for every i in 0..n, either Ti and Ui are the same types or both are reference types and Ui is a subtype ofTi; and
  • for every j in 0..m, there exists an h in 0..k such that Ej is a subtype of Xh.[/quote]

It is structural typing. No explicit declaration is needed to establish a subtype relationship between two function types, they may serve completely different purposes and one will be still considered subtype of the other if it is so determined by their structure

 

Serge Bureau replied on Wed, 2008/10/29 - 8:32am in response to: Slava Imeshev

[quote=imeshev]

Serge,

Jeroen Wenting two posts above just replied about me2 mentality, and I totally agree with him. I don't want closures. Some crappy obscure languages that have them don't mean that I have to want them. Java is perfect as it is. Just leave it alone, please.

More generally speaking, someone needed closures in Java has clearly skipped OOA/D course (if ever attended). No hire.

 

Slava

 

 

[/quote]

I could not care less about what you do not want.

 

Java perfect as is ????

Generics are a joke, autoboxing/unboxing is a ridiculous concept, annotations is the worst of them ??? This is the perfection, please get serious.

Jesper Nordenberg replied on Wed, 2008/10/29 - 8:35am in response to: J Szy

[quote=partyzant]

My, it's explicitly written in the spec:

[quote]A function type { T0 ... Tn => Tr throws E0, ... Em } is a subtype of function type { U0 ... Ul => Ur throws X0, ... Xk } iff all of the following hold:

  • Either
    • Tr is the same as Ur or
    • Both are reference types and Tr is a subtype of Ur;
  • n is equal to l;
  • for every i in 0..n, either Ti and Ui are the same types or both are reference types and Ui is a subtype ofTi; and
  • for every j in 0..m, there exists an h in 0..k such that Ej is a subtype of Xh.[/quote]

It is structural typing. No explicit declaration is needed to establish a subtype relationship between two function types, they may serve completely different purposes and one will be still considered subtype of the other if it is so determined by their structure

[/quote]

I don't agree. It's simply normal generics variance at use site, not structural typing. To quote from the spec: "function types do not add complexity to Java's type system because function types and their subtype relations can be understood as a straightforward application of generics and wildcards (existing constructs)".

For example if you have an higher-order function:

void myFunc({Number => String} fun)

it's simply translated to:

void myFunc(Function1<? extends String,? super Number> fun)

where Function1 is some system defined interface.

J Szy replied on Wed, 2008/10/29 - 9:19am in response to: Jesper Nordenberg

[quote=jn45229][quote=partyzant]It is structural typing. No explicit declaration is needed to establish a subtype relationship between two function types, they may serve completely different purposes and one will be still considered subtype of the other if it is so determined by their structure.[/quote]

I don't agree. It's simply normal generics variance at use site, not structural typing.[/quote]

It is specified to be implemented with generics' variance but it doesn't mean it's not structural typing. It is not just a syntactic sugar over generic types, it is another type discipline which will not be without influence on normal Java types. There is for example the closure conversion. To quote the spec once more:

[quote]Example: We can create a closure instance that adds two to its argument like this:

interface IntFunction {
int invoke(int i);
}
IntFunction plus2 = {int x => x+2};[/quote]

{ int => int } is no declared subtype of IntFunction here, but the assignment is possible and correct (even the method need not be named "invoke"). This is structural typing at work.

[quote]To quote from the spec: "function types do not add complexity to Java's type system[/quote]

...as shown above.

[quote]because function types and their subtype relations can be understood as a straightforward application of generics and wildcards (existing constructs)".[/quote]

"Straightforward application of generics and wildcards" is an oxymoron.

Jesper Nordenberg replied on Wed, 2008/10/29 - 10:06am in response to: J Szy

[quote=partyzant]

It is specified to be implemented with generics' variance but it doesn't mean it's not structural typing. It is not just a syntactic sugar over generic types, it is another type discipline which will not be without influence on normal Java types. There is for example the closure conversion.

[/quote]

Yes, the conversion of closures to any interface is quite magical I agree. However, that part is not required for a useful closure implementation in Java. In fact, without it the BGGA implementation would be similar to the one in Scala.

Comment viewing options

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