who needs asInstance...

[John Rose]

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