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

Want Closures in Java 7? Vote!

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

Vassil Dichev replied on Thu, 2008/10/23 - 1:59am

So where do we vote if we don't want closures for Java 7?

Ricky Clarkson replied on Thu, 2008/10/23 - 2:17am in response to: Vassil Dichev

You don't.  You instead get to say why you don't want closures, and based on your response, a pre-canned explanation of how you are wrong will come to a web page near you shortly.

Jesper Nordenberg replied on Thu, 2008/10/23 - 2:40am

The evaluation conclusion is quite funny:

"So, it's too late for Java - the costs are higher than they should be, the benefits lower. Sigh."

Oh well, I guess Java is f**ked forever because the Java libraries has already been designed. ;)

Behrang Saeedzadeh replied on Thu, 2008/10/23 - 3:32am in response to: Vassil Dichev

Exactly. For feature-requests the voting system should let us down-vote as well. 588 votes for Design-by-Contract!? We could just as well rename Java! What's next? Multiple inheritence? Pointers a la C? Explicit celanup of memory? Monads?

Otengi Miloskov replied on Thu, 2008/10/23 - 5:31am

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.

I think Closures is part for the modern programming languages, If Java doesnt include closures it will fell down and to the bottom maybe really will become more worst than Cobol is it now. To many mistakes has been and  I think now is good time to fix all this mess and include Closures and we need a proper event driven development in Java.

I thought SUN was the innovative and cool company but since the end of the 90's all changed, Microsoft it is doing pretty cool with C# 3 and .Net, If this doesn't resolve soon I will have to leave Java and go with C#. I dont want to live everyday with an outdated programming language.

By the way Scala and Clojure are cool but those not convence me, For the avarage Java programmer Joe are to complicate, to Functional programming. Java just need closures and a few more features but thats all.

Ricky Clarkson replied on Thu, 2008/10/23 - 6:04am in response to: Otengi Miloskov

C doesn't have closures.

How can a language be "too functional programming"?  It can only be not enough, unless the programmer is denying that mathematics underpins their work.

Lieven Doclo replied on Thu, 2008/10/23 - 6:24am

Now it's closures, tomorrow it's the next new hype Microsoft or PHP includes in their code. The argument 'Java needs Y, because language X has Y and it's so cool!' is just wrong in so many ways. You need to look at a functional level whether it pays to add a feature, not just because the competition has it.

That said, it's getting tiresome that every month someone new stands up and feels the urge to throw some new oil on the fire. I think all of us know by now that closures is a controversial subject, which will always have supporters as well as protesters.  If it gets into the language spec, fine, we'll deal with it. If it doesn't, don't whine and look at the alternative solution (which do exist).

Jess Holle replied on Thu, 2008/10/23 - 6:35am in response to: Behrang Saeedzadeh

Don't knock multiple inheritance.

If you've run across a case where you need it -- and they exist -- Java unnecessarily makes this a royal pain.

Clearly at this point you can't add multiple inheritance of classes, but you could add (1) non-public methods on interfaces and (2) default method implementations in interfaces [which would use the non-public methods in many cases, e.g. as virtual internal field accessors].

If you don't need to mix-in implementation as well as interface, that's great.  If you do, the lack of any means of mixing-in implementation (besides mass composition/delegation, which is excrutiating in this scenario and only remotely palatable via mass code generation) is really obnoxious in the extreme.

Just because a language feature makes your head hurt does not mean its bad.

On the flip side, just because it looks cool, shortens some sample code snippets, and is in other languages does not mean it is good.

Jess Holle replied on Thu, 2008/10/23 - 6:40am in response to: Jess Holle

P.S. I'm generally for closures but they clearly really have to sweat the details to ensure the right mix of power vs. complexity -- and ensure that blends well with existing APIs and traditions.

One thing that is a bit scary with closures is the "DSL trap" whereby you make your code look like it was written in something else than Java to the point that any other party reading it sees it as some other magical language.  That's not a good thing.  Today it is 100% clear to a competent Java programmer what any code snippet is doing.  Some closure patterns make this markedly less clear by making custom control structures look like part of the language, etc.

Ricky Clarkson replied on Thu, 2008/10/23 - 6:42am in response to: Lieven Doclo

Presumably it makes sense to look at why those other languages included closures.  They can't all have done it because other languages did it.

Lieven Doclo replied on Thu, 2008/10/23 - 7:14am in response to: Ricky Clarkson

[quote=rickyclarkson]Presumably it makes sense to look at why those other languages included closures.  They can't all have done it because other languages did it.[/quote]

Certainly... but you'd also have to take look at scope differences of the language itself. Putting a feature into a language can have serious different consequences depending on where it's used. Java and Haskell aren't even in the same ballpark... A feature in a scripting-type language can be completely useless and overly complex when applied to languages used to build enterprise class backend applications.

Ricky Clarkson replied on Thu, 2008/10/23 - 7:25am in response to: Lieven Doclo

Well, consider C#, the closest of those languages to Java.

Ricky Clarkson replied on Thu, 2008/10/23 - 7:27am in response to: Jess Holle

"Today it is 100% clear to a competent Java programmer what any code snippet is doing."

I suppose Java Puzzlers has no text inside it then.

Jesper Nordenberg replied on Thu, 2008/10/23 - 7:45am in response to: Lieven Doclo

[quote=doclolieven]

Now it's closures, tomorrow it's the next new hype Microsoft or PHP includes in their code. The argument 'Java needs Y, because language X has Y and it's so cool!' is just wrong in so many ways. You need to look at a functional level whether it pays to add a feature, not just because the competition has it.

[/quote]

You can't compare closures to some syntactic sugar included some hyped new language. Closures are a fundamental part of functional programming, without them it would be impossible (or at least very hard) to write useful higher-order functions. Java has objects so closures are not required in the language, and anonymous inner classes simplifies usage of closure-like constructs. The question is whether to add even more syntactic sugar so we get closer to the syntax found in functional languages. IMO, it would add value to the Java language, but it would still be a very clumpsy language for functional programming, so I'm not 100% certain it's a good idea. I would rather see more efforts put into a officially supported Java alternative suitable for functional programming, for example Scala or some other new language.

Lieven Doclo replied on Thu, 2008/10/23 - 7:46am in response to: Ricky Clarkson

[quote=rickyclarkson]Well, consider C#, the closest of those languages to Java.[/quote]

I've done my share of C# coding and I do love the concept of delegates. But at least you were able to read the code even if you didn't grasp the concept of delegates... you could even guess.

Try that with this:

{ String => { int => String } } concat = 
{ String s =>
{ int n => String r = ""; for ( ; n > 0; n--) r += s; r } };

 

Lieven Doclo replied on Thu, 2008/10/23 - 7:50am in response to: Ricky Clarkson

[quote=rickyclarkson]

"Today it is 100% clear to a competent Java programmer what any code snippet is doing."

I suppose Java Puzzlers has no text inside it then.

[/quote]

 Nice...

Mohammad Nour El-Din replied on Thu, 2008/10/23 - 8:03am

Sorry if this is a silly question, But what is the difference between Java inner classes and closures ?

And regardless the answer - which I really want to know - we can't just add closures to the Java language just because other languages have it. We should only do that if closures will add something to the Java language that it is not already has it.

Ricky Clarkson replied on Thu, 2008/10/23 - 8:12am in response to: Lieven Doclo

That looks to me like it takes a String s and an int n and gives you a String containing n copies of the String.  You wrote it a bit oddly, presumably to demonstrate the point that you would write bad code given closures.  There's nothing to stop you writing bad code in Java today, so feel free.

I would, with the BGGA compiler, write this:

public static String times(String s, int n)
{
StringBuilder builder = new StringBuilder();
for (int a = 0; a < n; a++)
{
builder.append(s);
}
return builder.toString();
}

Ricky Clarkson replied on Thu, 2008/10/23 - 8:23am in response to: Mohammad Nour El-Din

Mohammad,

Consider a hypothetical Java 6.5, where 'time' is a built in keyword that times a block of code, used in a similar way to synchronized.

time {

   my expensive code

}

There's not a lot of people who want that keyword, so perhaps we won't get it in Java, and we'll have to do this instead:

startTiming();

my expensive code

endTiming();

That's a bit annoying and error-prone, especially if used from within methods called within such a 'block'.

time(my expensive code) can't work, because my expensive code will be run before time even starts.  A Runnable can help:

time(new Runnable() {
public void run() {
my expensive code
}
});

That's full of noise about Runnable, and is far harder to read than the original imaginary keyword was. Worse still, if my expensive code contains 'return', 'this', 'break', 'continue' or 'throw' it starts to get very hard to wrap in the anonymous class.

With closures in the language, you could write:

time() {

    my expensive code

}

That's the control structure kind of use.  The other is stuff like Lists.filter(myList, { int x => x%2 == 0 }), which will give a new list containing only the even numbers from myList.  This kind is easier to write with anonymous classes than the first, but it would still be full of noise.

Jesper Nordenberg replied on Thu, 2008/10/23 - 8:30am in response to: Mohammad Nour El-Din

[quote=nourm]

Sorry if this is a silly question, But what is the difference between Java inner classes and closures ?

[/quote]

A closure is an "object" containing a function and bound values/variables that the function can access when called, so Java classes (including inner classes) are really a more general form of closures which can contain multiple methods/functions that access the same bound variables. The whole "Java closure" discussion is about adding syntactic sugar that makes it easier to define and instantiate classes containing only one method/function, ie function classes. Java already has some of this syntax sugar as an anonymous inner class method can access external values in scope at instantiation point (the compiler automatically generates code that injects these values into the created object).

Otengi Miloskov replied on Thu, 2008/10/23 - 8:32am in response to: Mohammad Nour El-Din

We need both Closures and first class functions so this works or even delegates but the more relevant example for me is for event programming in Swing or Wicket or GWT and a bunch more, anonymous inner classes are to verbose.


myButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("Hello World");
}
});

 

Instead could be:

myButton.addActionListener((ActionEvent e) { System.out.println("Hello World"); } );

 

Lieven Doclo replied on Thu, 2008/10/23 - 8:36am in response to: Ricky Clarkson

[quote=rickyclarkson]

That looks to me like it takes a String s and an int n and gives you a String containing n copies of the String.  You wrote it a bit oddly, presumably to demonstrate the point that you would write bad code given closures.  There's nothing to stop you writing bad code in Java today, so feel free.

I would, with the BGGA compiler, write this:

public static String times(String s, int n)
{
StringBuilder builder = new StringBuilder();
for (int a = 0; a < n; a++)
{
builder.append(s);
}
return builder.toString();
}

[/quote]

Hmm...  last post on this one, it's getting a 'yes it is, no it isn't' type of discussion again. The example is one I took from the BGGA site www.javac.info (see Advanced features). But that kinda proves one of my fears, it'll be easier to write bad code if even they write it like this. But can you honestly say you like that syntax? I'd take the snippet you wrote above any day of the week... If closures make it into the Java 7 spec, great, I'll probably use it extensively too, but I'd wish that wasn't a holy war started each month about the subject. We've heard it al before.

But at least, we can agree on disagreeing with each other...

Serge Bureau replied on Thu, 2008/10/23 - 8:55am in response to: Vassil Dichev

[quote=vdichev]So where do we vote if we don't want closures for Java 7?[/quote]

 

On another planet I hope

Serge Bureau replied on Thu, 2008/10/23 - 8:58am in response to: Ricky Clarkson

[quote=rickyclarkson]

C doesn't have closures.

How can a language be "too functional programming"?  It can only be not enough, unless the programmer is denying that mathematics underpins their work.

[/quote]

 

What complex system did you write in C ???

I have not used it in 15 years !

Yardena Why replied on Thu, 2008/10/23 - 9:07am

The votes now trippled! Thanks Tim for posting. Ricky - thanks for answering and explaining over and over.  :-)

Ricky Clarkson replied on Thu, 2008/10/23 - 9:10am in response to: Serge Bureau

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!

Ricky Clarkson replied on Thu, 2008/10/23 - 9:18am in response to: Lieven Doclo

If you look again, you didn't take it from the BGGA site, but from a blog linked to from there.  With the explaining comments around it, it makes sense as a small example.  For currying I would rather use arithmetic operators for examples.

{ int, int => int } plus = { int x, int y => x + y }; //this is not curried.

{ int => { int => int } } plus = { int x => { int y => x + y } }; //this is curried.

The useful thing about currying is that you can then partially apply the function, e.g., using the second 'plus' above, plus.invoke(3) gives a function that will add 3 to anything given to it.  It's much better in Haskell:

> map (+2) [1, 2, 3]

[3, 4, 5]

Ricky Clarkson replied on Thu, 2008/10/23 - 9:20am in response to: Yardena Why

I don't mind.  Each time I do it, hopefully I explain it better.  If I can't, then the pre-canned responses will come out. :)

J Szy replied on Thu, 2008/10/23 - 12:07pm 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]

So what? All of the above either have already failed or achieved their success before introducing closures.

Hardly a reason to include, rather to avoid.

[quote]I think Closures is part for the modern programming languages, If Java doesnt include closures it will fell down and to the bottom maybe really will become more worst than Cobol is it now.[/quote]

I've already read someone's post here that Java must include closures, or else it'll get nuked in the blogosphere. :-)

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

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.

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.

I don't want happend that to Java, I want Java evolve because still a great language just need few very few features to keep it up with the new technology. That does not affect to people that are not interested in Closures, Don't use closures if you don't want to, period.

Programming languages are tools not religions.

 

Comment viewing options

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