BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Closures Proposed for Java SE 7

Closures Proposed for Java SE 7

Bookmarks
Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé (some of the main architects of the Java language) on Friday put out a proposal for adding closures and local functions to Java SE 7, a feature that Smalltalk users always raved about, which is common in scripting langauges and even C# supports them. 
For programming in the small, closures allow one to abstract an algorithm over a piece of code; that is, they allow one to more easily extract the common parts of two almost-identical pieces of code. For programming in the large, closures support APIs that express an algorithm abstracted over some computational aspect of the algorithm. We propose to add function types and closures to Java. We anticipate that the additional expressiveness of the language will simplify the use of existing APIs and enable new kinds of APIs that are currently too awkward to express using the best current idiom: interfaces and anonymous classes.
Peter commented further on how anonymous classes aren't good enough to simulate closures.   Gilad Bracha blogged a bit about why the proposal is coming now, saying that "the widespread adoption of scripting languages has exposed a lot of people to the idea of first class functions. It has also shown that another argument used against closures - that they are too abstract for ordinary programmers - is just as imbecilic as the one about customer demand." 

DWR founder Joe Walker also wrote about how the Collections classes would need to be modified to support closures:
void(int) totalizer = (int i) : total = total + i;
totalizer(1);
totalizer(2);
System.out.println(total); // Prints 3
int total=0;

But what you really want is to be able to do things like this:

int[] numbers = new int[] { 100, 200 };
numbers.each(totalizer);
System.out.println(total); // Now prints 303;
Javalobby posted a link to the proposal on Friday which drew a large discussion of developers mostly supportive of the idea.   Neal Gafter on saturday wrote a detailed justification of the benefit of closures,  showing a set of code samples and how closures simplified them significantly. Neal's conclusion: closures "allow you to easily abstract away aspects of code that would otherwise require complex contortions.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Or..."Closures proposed for Java 2015"

    by Clinton Begin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yeah, I think Sun should adopt the old Windows version convention of using years, so that nobody is confused about when they'll actually be able to use this.

    If Sun wants to have ANY hope of keeping Java moving as fast as it needs to, here's what they need to do one thing:

    Separate the release cycles of javac, java and rt.jar. In other words, let the Java language, the Java VM and the core class library evolve at different speeds. Obviously there will be dependencies, but with these three things, it's pretty easy to figure out:

    JVM <- Java <- Core Classes

    The nice thing is that most of the features I want in Java won't require a change to the JVM. Furthermore, the JVM changes the least often, then Java and the core class library changes the most -- usually with additions rather than changes.

    I think this would dramatically increase the speed at which some of these features can be realized.

    Closures will not require a change to the VM...so why do we need to wait 6 years before we see it?

    Clinton

  • Re: Or...'Closures proposed for Java 2015'

    by Floyd Marinescu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Clinton, that sounds like a fine idea. I suppose there could be questions about compatibility (would you have to version the JVM separately from the language and core classes?), but it could work.

  • Re: Or...'Closures proposed for Java 2015'

    by j c,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Java has claimed to be best of breed of general purpose for a long time. Rather than me too, is there anything better about Java closures or is this just another game of catch up which not many people will be interested in?

    the article starts...Modern Languages do THIS. Oh you mean except for Java. And we all made excuses for the lack of it for years as if we prayed to SUN to do it and noone did noone wanted it until the SHINE of Java wore off a bit and now its like a direction?

    Sounds like a patch.

  • Gilad Bracha will be happy

    by Joost de Vries,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Back in 2001 when jsr 14 (generics) was in public review I consciously allowed myself to be idealistic/naive enough to give feedback to this review; I made the familiar argument that generics plus anonymous inner classes almost equals closures so only minimal syntactic sugar would be needed.

    Gilad Bracha was gracious enough to react and say that he did not expect it to happen after arguing 6 yrs for closures.

  • Is it really needed?

    by Bahadir Yagan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am not an expert on the subject but after reading for a while, it looked like C++ Function Objects or C function pointers. I don't see any good in making the language more complex with such constructs.

    Apart from the API we have, it looks like the Java itself will endup C++ with GC.

  • PL1/C++ Syndrome

    by Diego Visentin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    IMHO, Java and C# are following the PL1 or C++ path, ie add complexity on every language revision without understand that there isn't a good language for everykind of work. Java and C# run over a VM, so you can use other specific languages for specific tasks, like VB.NET or Groovy or Lisp, is supported by desing.
    So, why can we try to add complexity to a 'clear' language?

    PS: with modern multi-language IDE like Eclipse is really simple for a developer to master multiple language artifacts per project like html, javascript, sql, java; add to this list groovy/jruby/jpyhon/jlisp/etc. and leave java (language) small and simple.

    Ciao, Diego

  • Re: Or...'Closures proposed for Java 2015'

    by Clinton Begin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    >>Modern Languages do THIS. Oh you mean except for Java.

    Hmmm...modern languages...

    Like the 12 year old Ruby language?


    Java was out of date the day it came out. Back then it didn't have to try hard, because it was competing against crap (VB and Perl). Sun failed to compete when they needed to.

    Cheers,
    Clinton

  • Re: Or...'Closures proposed for Java 2015'

    by j c,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    >>Modern Languages do THIS. Oh you mean except for Java.

    Hmmm...modern languages...

    Like the 12 year old Ruby language?


    Java was out of date the day it came out. Back then it didn't have to try hard, because it was competing against crap (VB and Perl). Sun failed to compete when they needed to.

    Cheers,
    Clinton


    Exactly

  • Re: Is it really needed?

    by Diego Visentin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Often we talk about closures about simply logic over a collections when this logic is expressable with a single function.
    So maybe it's sufficient something like FunctionalJ:
    functionalj.sourceforge.net/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT