Closures: Open Issues (v0.6a)
- Can Method Handles be used for Function Types?
It isn't obvious how to make that work. One problem is that Method Handles
reify type parameters, but in a way that interferes with function subtyping.
- Can we get rid of the explicit declaration of "throws" type
The idea would be to use disjuntive type inference whenever the declared
bound is a checked exception type. This is not strictly backward
compatible, but it's unlikely to break real existing code. We probably can't
get rid of "throws" in the type argument, however, due to syntactic
- Disallow @Shared on old-style loop index variables
- 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
- 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.
- 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.
- How are class literals for function types formed?
Is it #void().class ? If so, how does it work if object types are
erased? Is it #?(?).class ?
- The system class loader should dynamically generate function type interfaces.
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.
- Must the evaluation of a lambda expression produce a fresh object each time?
Hopefully not. If a lambda captures no variables from an enclosing
scope, for example, it can be allocated statically. Similarly, in other
situations a lambda could be moved out of an inner loop if it doesn't
capture any variables declared inside the loop.
It would therefore
be best if the specification promises nothing about the reference
identity of the result of a lambda expression, so such optimizations
can be done by the compiler.
Closures for Java by Neal Gafter and Peter von der Ahé is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.