Public Review

Howard Lovatt howard.lovatt at gmail.com
Tue Mar 8 15:15:23 PST 2011


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.

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.

-- Howard.

>> Browsing through the javadoc for java.lang.invoke I noticed the
>> following (nit picky things that are trivial but should be fixed
>> anyway):
>>
>> 1. Description of MethodHandle: says "// mt is { =>  int}", should say
>> "// mt is ()int"
>> 2. Description of MethodHandle.asType(MethodType): no full stop; end
>> of first sentence
>> 3. Description of MethodHandles.dropArguments(..., List<Class>) and
>> Description of MethodHandles.dropArguments(..., Class...) interchanged
>>
>>
>>    -- Howard.
>
> R?mi


More information about the mlvm-dev mailing list