Public Review

[Howard Lovatt]

John,

Thanks for your detailed response to my comments. It sounds like you
are already well aware of my concerns and have plans in place to look
at these issues, which is great to hear.

I would add that Charles Nutter's Binder concept looks good,
particularly using a sequence of . separated calls instead of
individual static method calls and working the other way round (from
the type of the resulting handle and binding the existing handle at
the end).

>> 3. Description of MethodHandles.dropArguments(..., List<Class>) and
>> Description of MethodHandles.dropArguments(..., Class...) interchanged
>
> I can't find this bug; I double-checked the docs and they are correct:
>
> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-pr/java/lang/invoke/MethodHandles.html#dropArguments(java.lang.invoke.MethodHandle,%20int,%20java.util.List)

The reason you can't find this bug is my poor description of the
problem. It is the example under the List version of
MethodHandles.dropArguments that is incorrect. That example should be
under the varargs version, since it uses varargs.

Sorry for the confusion re. dropArguments and thanks again for your
all the great work,

 -- Howard.

On 23 March 2011 12:52, John Rose <john.r.rose at oracle.com> wrote:
> On Mar 6, 2011, at 3:25 PM, 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.
>
> Thanks, Howard!
>
>> 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?
>
> Broadly speaking, there are at least four cases:
>
> 1. SAM conversion, which is a Project Lambda concept that depends on detailed, complex, and as-yet-undetermined rules.
>
> 2. Simple, fast binding of a single method handle to an interface with a corresponding abstract method.
>
> 3. General, fast binding of a group of method handles to an interface with a corresponding group of methods.
>
> 4. Case #3, but for arbitrary types and methods (abstract or non-final).  Requires detailed story for constructor calling and access control.
>
> Doing #1 is physically impossible in JDK 7.  I'm no longer using the term "SAM" to avoid confusion.
>
> The MHs.asInstance call is #2.  Handling a single method is intrinsically simpler than handling multiple methods, from the points of view of both users and JVM implementors.  It is an 80% use case.  (The 20% cases include things like Iterator.)  It is also likely that JVMs will be able to optimize such things better than the general case.  So we're relatively confident that this will be useful and beneficial, and will not be made out of date by developments in JDK 8 (possibly #3 or #4).
>
> We have several ideas how to do #3 and even #4, but it is too early to tell which to choose.  Project Lambda and user experience in JDK 7 will tell us more.
>
> My favorite solution (at the moment) is a two-phase factory.  In this pattern, all the strange degrees of freedom (which methods in what order, constructor selection, access and type checks) are resolved in a first phase.  The first phase might involve multiple builder-style calls, but it eventually produces a constructor.  The second phase consists of invoking the constructor (a method handle, naturally) on a set of positional arguments (method handles to bind, plus constructor arguments if needed).  The second phase can run very fast and be inlined if the first phase works hard to produce a good constructor.  The first phase is eminently suitable for executing in a bootstrap method.
>
>> 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"
>
> Thanks; fixed.
>
>> 2. Description of MethodHandle.asType(MethodType): no full stop; end
>> of first sentence
>
> Good catch.
>
>> 3. Description of MethodHandles.dropArguments(..., List<Class>) and
>> Description of MethodHandles.dropArguments(..., Class...) interchanged
>
> I can't find this bug; I double-checked the docs and they are correct:
>
> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-pr/java/lang/invoke/MethodHandles.html#dropArguments(java.lang.invoke.MethodHandle,%20int,%20java.util.List)
>
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
  -- Howard.