Lambda and JSR 292 method handle

[Neal Gafter]

I don't think there is an option to reify function types.  That's because
generics are already non-reified.  In this code

*<T> #T() constant(T t) {
    return #() t;
}
*

the returned lambda cannot, in principle, be reified if generics are not
reified.  This is independent of whether function types are mapped to
interfaces, method handles, or something else.  There may be issues with it,
but they aren't "disadvantages" except by comparison to a scheme that does
not have these issues, and no such scheme has been proposed.

On Wed, Dec 23, 2009 at 1:06 PM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> Presumably the problems with using generic style annotations and erasing
> the
> actual type include:
>
>   1. Can't have two methods of the same name only distinguished by lambda
>   type, e.g. filter( #boolean(int) ) and filter( #boolean(float) )
>

These are distinguished in CfJ, but not in a hypothetical erasure to
MethodHandle.


>   2. Can't have arrays of lambdas that are type safe, e.g. new #(int)()[ n
>   ]; // Illegal
>

Right.


>   3. Can't have instanceof tests (this might be possible since type
>   information is carried at runtime)
>

No, type information cannot, in principle, be guaranteed to be available at
runtime unless generics are reified.


>   4. Can't have primitive types (this might be fixable with an extension to
>   the signature attribute)
>   5. Can't have static fields that are lambdas (this might be fixable with
>   an extension to the signature attribute)
>

Right: the signature attributes would be extended to express function types,
addressing these two issues.