Alex Buckley asked me to include BGGA and other documents in messages on
this list, so that they may formally be considered contributions to project
lambda.
Enclosed please find the issues list associated with the BGGA
specification. It may also be found at <
http://www.javac.info/issues-v05.html>.
Closures: Open Issues (v0.5)
- Make it easy to yield a result early from a closure. It should be as
easy to yield a result early from a closure as returning from a method.**
- Should support for currying be directly in the language? Bound method
references?
- *Handle interfaces like Comparator that define more than one method*,
all but one of which will be implemented by a method inherited from
Object.
The definition of "interface with a single method" should count only
methods that would not be implemented by a method in Object and should
count multiple methods as one if implementing one of them would implement
them all. Mainly, this requires a more precise specification of what it
means for an interface to have only a single abstract method.
- *Specify mapping from function types to interfaces*: names, parameters,
etc.
We should fully specify the mapping from function types to
system-generated interfaces precisely.
- *Type inference*. The rules for type inference need to be augmented to
accomodate the inference of exception type parameters. Similarly, the
subtype relationships used by the closure conversion should be reflected as
well.
- *VM support for null*
The verifier already supports null, including in the verifiers, but there
is no way to specify null as a method argument or return type. We need a way
to specify null in a signature (that is, a new signature letter).
- *Elided exception type parameters* to help retrofit exception
transparency.
Perhaps make elided exception type parameters mean the bound. This
enables retrofitting existing generic interfaces that don't have a type
parameter for the exception, such as java.util.concurrent.Callable, by
adding a new generic exception parameter.
- *Document the new unchecked Throwables for nonlocal transfers*.
- *Should javac detect the most common problematic interactions catching
nonlocal transfers?
*The most likely case may be completely local within a single method,
when a nonlocal transfer has a try-catch between the transfer and its
target.
- *volatile on locals*.
We should say it is allowed.
- *How are class literals for function types formed?*
Is it {?=>?}.class ?
- *The system class loader should dynamically generate function type
interfaces.
*The interfaces corresponding to function types should be generated on
demand by the bootstrap class loader, so they can be shared among all user
code. For the prototype, we may have javac generate these interfaces so
prototype-generated code can run on stock (JDK5-6) VMs.
- *Can or should javac inline some invocations of control abstraction
APIs?
*If so, how will it decide which ones? Does the inlining happen at the
bytecode or source level? Will javac handle break/return/continue
efficiently when these are inlined? Or is this something should be left for
the VM to handle? (Hotspot already seems to handle the most important cases)
- *Do we need any new reflection support for closures?
*For function types? For null? Probably not because of the information
available in the defining (not bridge) methods.
- *Should a labelled for control invocation statement* interact with
labelled break and continue?
- *Should for be a modifier* (before the return type in a method
declaration) or appear next to the name?
- *Would explicit VM support for nonlocal transfers improve performance?*
- *Should we request VM support for proper tail recursion?*
- Should we support (parametric) polymorphic function types? Probably
not.
------------------------------
[image: Creative Commons
License]<http://creativecommons.org/licenses/by-sa/3.0/us/>
Closures for Java by Gilad Bracha, Neal Gafter, James Gosling, Peter von der
Ahé <http://www.javac.info/> is licensed under a Creative Commons
Attribution-Share Alike 3.0 United States
License<http://creativecommons.org/licenses/by-sa/3.0/us/>.