Summary: Add support so programs can operate on an arbitrary block of code with parameters, and simplify the use of methods that receive such blocks.
Identification (JCP Member submitting this proposal): TBD
Name of Contact Person: TBD
E-Mail Address: TBD
Initial Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)
Neal Gafter, spec lead
Osvaldo Pinali Doederlein (SouJava)
Larry Cable (BEA)
Supporting this JSR (alphabetically):
[Note: Google has not committed to support a Closures JSR]
Peter von der Ahé
Joe Walker (DWR)
This JSR provides support for operating on an arbitrary "block of Java code", or body, which is either a statement list, an expression, or a combination of both. We call the mechanism a closure expression. Wrapping statements or an expression in a closure expression does not change their meaning, but merely defers their execution. Evaluating a closure expression produces a closure object. The closure object can later be invoked, which results in execution of the body, yielding the value of the expression (if one was present) to the invoker. A closure expression can have parameters, which act as variables whose scope is the body. In this case the invoker of the closure object must provide compatible arguments, which become the values for the parameters.
In addition, this JSR may support a new invocation statement for methods that accept a closure to simplify their use in common cases.
The results of this JSR will be suitable for inclusion in the Java SE and EE platform specifications.
We will detail JLS and possibly JVM specification changes. As such, the changes can be implemented in a wide variety of environments.
The specification will improve the Java Programming Language by:
a. Closures can be used to simplify the clients of many existing APIs that are currently invoked by the creation of anonymous class instance creation expressions (JLS 15.9.5). Examples include the appearance of callbacks in various APIs such as javax.swing, and asynchronous tasks such as java.lang.Runnable and java.util.concurrent.Callable. Closures eliminate many of the pain points that are associated with anonymous inner classes:
b. Closures enable the development of powerful libraries that can help simplify the code required to solve common problems such as resource termination. For example, one pain point in Java is the verbosity and awkwardness of resource termination, such as unlocking a lock or closing a stream. With the addition of closures, methods can be defined to eliminate these pain points. These Control APIs are methods in which controlled statements are received as closures. The definition and use of such APIs may be improved by the addition of a shorthand invocation statement syntax in which a controlled statement appears last. The following are a number of specific methods that the expert group may consider adding to the JDK. These statements illustrate one possible usage syntax that is to be considered a tentative placeholder; the specific syntax and method names is subject to consensus of the expert group:
c. Closures will improve the use of Java for concurrent programming using the java.util.concurrent framework, by allowing programs to create instances of interfaces such as java.lang.Runnable and java.util.concurrent.Callable, thus simplifying many applications that rely on existing concurrency APIs. Extensions of the existing concurrency APIs to take advantage of closures, such as the previously mentioned withLock method, will make some kinds of concurrent programming much simpler. For another example, we will specify APIs that enable concurrent loops to be written as easily as if concurrent loop statements had been added to the language.
d. A style of programming using aggregate operations will be convenient enough to become practical with the presence of closures in the language. Aggregate operations typically appear in functional programming languages, and involve the application of some operation to every member of a collection. Aggregate operations include map, reduce, fold, and filter. These typically support concurrency because many of the component operations may take place in parallel. Such applications often require no additional explicit synchronization by clients beyond the implicit fork and join of the aggregate operations, and this fact enables a more efficient implementation than with a more general concurrency framework. The expert group may specify a set of concurrent aggregate APIs that integrate smoothly with closures.
e. The addition of closures simplifies the evolution of the Java platform. Many existing language RFEs in Sun's public bug database can retargeted as API requests for methods that receive closures. Many future needs for additional statement forms can instead be met by the addition of library methods.
Closures have been shown to be a very powerful abstraction mechanism, enhancing the power of a programming language in ways not available to Java programmers today:
When closures are integrated into an object-oriented type system with subtyping, the types used to represent them obey a relationship that enables them to be used quite flexibly. See, for example, Scala http://www.scala-lang.org/, section 3.2.9. This enables a flexibility available in untyped languages such as Scheme, Ruby, and Smalltalk and which is achieved only with extreme awkwardness in Java today. This does not require an extension to the type system, as Java's generics and wildcards already obey the necessary typing relationships.
Because this is a proposed extension to the Java Programming Language, the primary base document is the Java Language Specification. For any required VM changes the base document is the Java VM Specification. In both cases, we will specify the required changes as addenda to these base documents sutiable for integration in a new edition. Changes to existing J2SE APIs will be based on the JDK7 platform specification. The prototype will be based on the openjdk platform implementation.
A description of the problem space to be addressed by closures appears at http://gafter.blogspot.com/2007/01/definition-of-closures.html. The base specification for new features is an existing proposal by Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé entitled Closures for Java (v0.5) (http://www.javac.info). An early prototype is available at http://www.javac.info/closures.tgz. The expert group may draw from these in developing a specification and reference implementation for this JSR. No draft TCK is publicly available at the time of this writing.
The primary changes will be to the language; any classes and interfaces added for language support will likely appear in java.lang and its subpackages. Additional APIs using these constructs are likely to be specified in java.util, java.util.concurrent, and possibly java.io.
No. It is possible that as a result of the proposal some existing security APIs may be significantly easier to use.
Trivial. Some new compiler error messages might need to be issued in different languages.
The Java Language Specification is likely to require an addendum or revision if the results of this JSR are integrated into a platform specification. Additional minor changes may be required in the Java VM specification.
The JSR will aim to release an EDR (early draft release) within the first six months and reach a maturity level appropriate for inclusion in a Java SE platform release one year after that. We anticipate completing this work in time for inclusion into Java SE Release 8.
Most interactions will take place via email over a publicly-readable list. Teleconferences and in-person meetings will be held on an as-needed basis.
See 2.14. We will also maintain a separate open mailing list for discussions by other interested people outside the expert group. Drafts of proposed specification changes required to incorporate these features into the platform will be published, under the Gnu Free Documentation License version 1.2, for public review. Drafts of proposed TCK addenda required to incorporate these features into the platform will be published, under GPLv2, for public review. We will provide prototypes (as early as possible), distributed under GPLv2, reflecting the sense of the expert group, so that the community can try the proposed language constructs in realistic settings.
We will work with IDE vendors to demonstrate support in IDEs. The IDE support will not be subject to specification or TCK, but rather to enable community members to try the language features using their preferred tools, and to demonstrate that it is feasible to integrate the features in existing IDEs.
This JSR proposes changes to the Java language and thus can only be delivered in a Java SE platform release.
This is a new specification.
The Specification, Reference Implementation, and TCK will be made available as part of some future Java SE platform release. This JSR therefore will not be licensed separately and does not have its own separate business terms.
See section 2.7, above.
The existing Java platform documents provide a starting point, for which the expert group will specify the addition of features to satisfy the requirements of this JSR. The base Closures specification is one approach to providing the desired features. The expert group may draw from that base specification and others.
The expert group may additionally consider extensions that provide support for currying, and specifically the special case of treating bound method references as closures. For example, see the "eta expansion" of Scala (http://www.scala-lang.org/docu/files/ScalaReference.pdf, 6.25.5), and "invocable method references" in First-class methods: Java-style closures (version 0.5) by Stephen Colebourne and Stefan Schulz (http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc).
The expert group may consider additional extensions that improve compile-time checking of the use of closures within the language. For example, concurrent aggregate operations are more easily parallelized when the constituent operations satisfy certain conditions such as being wait-free, free of side-effects, or free of interference. The expert group may consider marker interfaces or annotations, and related language constraints or annotation processors, that help check or enforce these constraints. For example, the base specification proposes the marker interface RestrictedFunction that enforces constraints mirroring those of Java's existing inner classes.
Additional extensions may be necessary in Java's reflection system, in JSR 269's annotation processor API, and/or in JNI to reflect the language constructs added by this JSR.
This preliminary proposal Copyright © 2007, Neal M Gafter