who needs asInstance...

[John Rose]

Right.  We figured people already generating lots of wrappers (like JRuby in particular) would not miss asInstance as much.

OTOH, as Robert Fischer just pointed out, it often helps to have a paradigm bridge.

And if the bridge is built by the platform, it is likely to be fast and solid.

-- John

On Apr 2, 2011, at 5:29 PM, Charles Oliver Nutter wrote:

> I'd use it if there, but we already generate so much bytecode at
> runtime, including non-Proxy "real" implementations of interfaces,
> that it's really not a big deal if it isn't there.
> 
> However...the fact that I *would* use it means that eventually I
> *will* use it, which then means yet another item I need to support
> multiple mechanisms for. In the case of interface impl, that means I'd
> be maintaining:
> 
> * Proxy-based version for systems that disallow loading user bytecode
> * JRuby's own bytecode-based interface impl
> * asInstance-based interface impl (for single-method interfaces, at least)
> 
> I'm not complaining, just pointing that out :)
> 
> - Charlie
> 
> On Mon, Mar 28, 2011 at 5:37 PM, 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
>> 
>> P.S.  Brief background:  Many function-like types defined in existing (pre-7) Java systems are defined as single-method interfaces.  Runnable is the canonical, aboriginal example.  There are other ways to do function-like types, too, such as abstract classes and multiple-entry interfaces (a Function that takes one entry point per arity, for example.)  But the most common pattern is a single-method interface.  In order to encourage people to use method handles, we would like them to feel free to use them in new code, even if this requires "wiring them up" to older APIs that feature function-like types.  The simplest thing (not the only thing) we can do to help with this is to provide a proposed MethodHandles.asInstance API.  We expect that people with more complex needs will have to spin bytecodes to wire up method handles to more complex types.  We (the 292 EG) hope to provide a more comprehensive interoperation between method handles and interfaces in JDK 8, as previously d!
>>  iscussed.  A final point:  SAM types are not going to be the same as single-method interfaces for a host of reasons currently being thrashed out by the Lambda EG.  The JSR 292 EG is not going to get into language interactions, but instead is going to always take a JVM-centric view, defining APIs in terms of JVM-level metadata and operations; this is the sanest way to provide multi-language support.
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>