who needs asInstance...

[Howard Lovatt]

I don't think it would really matter if there was:

java.lang.Class.asSAMInstance(mh)

and

java.lang.invoke.MethodHandles.asInstance(mh, interface)

That did a similar thing, the Javadoc could just describe them as
alternative ways of doing the same or similar (perhaps the Class
version would have more features than the MethodHandles version and
then the MethodHandles version could be deprecated).

A bigger deal might be if an object created by
MethodHandles.asInstance wasn't interchangeable with one created by
MethodHandles.asInstance because they:

1. Handled argument/return type conversion differently
2. Overrode methods from Object differently
3. Had different creation/execution time profiles which made it
impractical to substitute an instance created by
MethodHandles.asInstance for an instance from Class.asSAMInstance

In which case, steer clear.

 -- Howard.

On 29 March 2011 10:53, John Rose <john.r.rose at oracle.com> wrote:
> On Mar 28, 2011, at 4:43 PM, Howard Lovatt wrote:
>
>> a) Easy to do
>
> Yes, it's easy to do.  (Done now with Proxy, in a poor-man's way, and simple to improve upon.)
>
>> b) Doesn't prevent anything Project Lambda might want to do (and
>> preferably be a step along the way)
>
> That's the issue.  Lambda must come up with their own fully-defined concept of SAM, and will then (probably) want to define a conversion routine that interoperates with JSR 292.  Perhaps something like java.lang.Class.asSAMInstance(mh); nobody knows at this point.  What we do know is that (a) JSR 292 can only define things at the JVM level, and (b) Lambda is likely to need something different (notably, bridge methods driven by complex language-specific rules).
>
> Putting a conversion into java.lang.invoke.MethodHandleProxies doesn't strictly prevent doing something Lambda-like in java.lang.Class, but we want to avoid having two things (one from 292 and one from Lambda) which do *almost* the same thing.  If there's no clear difference, we introduce a tricky dilemma to users; the risk is that they will choose at random and then have to fix code that acts surprisingly.  I think clear naming and clear definitions will address this risk, but unless someone is going to actually use the JVM-level thing in the JDK7 (Java SE 7) time frame, it's a little bit safer to punt for 8.  Of course, there are risks with that too.  Hence my questions to the community.
>
>> As an aside, I think it is great that you ask these questions and
>> consider the responses from the wider community.
>
> I'm glad!
>
> -- John
>
>> Cheers,
>>
>> -- Howard.
>>
>> On 29 March 2011 09:37, John Rose <john.r.rose at oracle.com> wrote:
>>> You may have noticed that the JSR 292 API includes a conversion operator (called MethodHandles.asInstance) to allow a method handles to interoperate with single-method interfaces, such as Runnable.  This is a small but (maybe) useful subset of the SAM conversion which is being defined by Project Lambda.
>>>
>>> The Public Review document even mentions "SAM" types, although we are removing that terminology, since it is out of scope for JDK 7.  There is a proposal to remove asInstance from the API altogether, leaving users to solve interoperability by whatever combination of hand-written adapter classes and bytecode spinning.
>>>
>>> Here's my question:  Who plans to use asInstance in JDK 7?  What would it cost you if we were to omit it from JDK 7, and you had to wait for the full SAM-integrated version in JDK 8?
>>>
>>> Thanks,
>>> -- John
>
>



-- 
  -- Howard.