Public Review

[Howard Lovatt]

I am missing something:

> 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.

There is only one copy of the instance method table per class (in this
case methodHandle type), so I don't see that the overhead of extra
instance methods is that great.

 -- Howard.

On 9 March 2011 10:26, Rémi Forax <forax at univ-mlv.fr> wrote:
> 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
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
  -- Howard.