JDK-5014235 : Closures support instead of anonymous inner classes
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.2.0,1.3.0,1.4.0,1.4.2,5.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS:
    generic,linux,linux_redhat_9.0,windows_2000,windows_xp generic,linux,linux_redhat_9.0,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-03-16
  • Updated: 2011-10-31
  • Resolved: 2011-10-31
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
Look at JSR 241 <http://jcp.org/en/jsr/detail?id=241>.
Particularly to closures <http://groovy.codehaus.org/closures.html>.

I wish I could code this way Runnables, PropertyChangeListeners, ... all typical single method annonymous inner classes that clutter my code.
###@###.### 2004-03-16
###@###.### 2004-03-16

Comments
EVALUATION Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot). All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1. This specific request to change the Java programming language is related to the work of OpenJDK Project Lambda. It will be considered further by that project, not here. The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.
31-10-2011

PUBLIC COMMENTS Too late.
02-10-2004

EVALUATION I've been saying this for more than seven years. Closures are a great thing. Unfortunately, Java missed the boat in 1997. Since then, we've added a collections framework without closures (one of the prime uses), built graphics APIs around nested classes etc. We have tons of control constructs that could be defined using closures but aren't (assert and foreach, for example). So the advantage of adding closures now would be relatively small compared to the huge benefit you get if you add them from day one. Implementing them is quite painful (though I think I've worked out how to do it) without VM support. And dealing with all the special cases around break, continue etc. is a mess. So, it's too late for Java - the costs are higher than they should be, the benefits lower. Sigh. In short, ###@###.### 2004-07-09
09-07-2004