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
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
