Public Review

[Rémi Forax]

On 03/09/2011 12:15 AM, Howard Lovatt wrote:
> R?mi Forax<forax at univ-mlv.fr>  wrote:
>> Hi Howard,
>> thank you for your comments.
>>
>> On 03/07/2011 12:25 AM, Howard Lovatt wrote:
>>> The new API looks great. I think all the simplifications made,
>>> particularly around CallSite and no longer having a Bootstrap, have
>>> really helped. The methods isWrapperInstance, wrappedInstanceTarget,
>>> and wrapperInstanceType are nice additions to the API.
>>>
>>> The requirement that a SAM (in MethodHandles.asInstance( ... )) must
>>> be public and must by an interface is a bit restrictive. Could either
>>> or both limitations be removed earlier rather than latter?
>> There are really few issues, we are still talking. asInstance is one of
>> them.
>> because specifying it is not that easy.
>> Supporting abstract class is even more tricky.
>> Moreover supporting abstract class requires a constructor without argument
>> thus make asInstance() not useful for a lot of abstract classes.
> One possibility is to add extra asInstance methods:
>
> asInstance( MethodHandle target, Class<T>  abstractClass, MethodType
> constructorTypes, Object... args )
> asInstance( MethodHandle target, MethodHandle constructor, Object... args )
>
> So that the correct constructor can be selected and arguments passed to it.
>
> More general comments on the API:
>
> 1. Replace all the static methods in MethodHandles that have a target
> as their argument (typically first), e.g. asInstance, with instance
> methods in MethodHandle. It makes the API much easier to use.

Core methods are in MethodHandle. Others are in MethodHandles.
from the implementation point of view, core method can be implemented
differently depending on the kind of MethodHandle;
Also, having a lot of virtual methods as a cost in memory which can be
important if the all method handle kinds are subtype of MethodHandle.

> 2. Add methods to extract the class that the method was looked up in
> and name of the method to MethodHandle, e.g. getLookupClass() and
> getName(). These are useful in keeping track of method handles,
> particularly for error reporting.
>
> 3. Add reflect methods to match the unreflect methods for conversion
> from MethodHandles to core reflection. Useful when you need to
> interact with an old API.

Those two items are open issues for JSR292 v2 :)

> -- Howard.

Rémi