Closures Proposed for Java SE 7

Posted by Floyd Marinescu on Aug 21, 2006

Sections

Development,

Architecture & Design

Topics

Programming ,

Java

Tags

Java SE ,

Closures ,

Language Features

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.

1. Back to top

   Or..."Closures proposed for Java 2015"

   by Clinton Begin

   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

   Reply

2. Back to top

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

   by Floyd Marinescu

   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.

   Reply

3. Back to top

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

   by j c

   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.

   Reply

4. Back to top

   Gilad Bracha will be happy

   by Joost de Vries

   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.

   Reply

5. Back to top

   Is it really needed?

   by Bahadir Yagan

   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.

   Reply

6. Back to top

   PL1/C++ Syndrome

   by Diego Visentin

   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

   Reply

7. Back to top

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

   by Clinton Begin

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

   Reply

8. Back to top

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

   by j c

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

   Reply

9. Back to top

   Re: Is it really needed?

   by Diego Visentin

   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/

   Reply

• Older >