Hi John,
I haven't full thought through it (Jochen is more up-to-date than me
on indy, mh and friends than I am), but in Groovy, we have various
areas where we do various conversions and coercions, like maps
([run:{...}] as Runnable) and closures coercions ({->} as Runnable) to
SAM types, or things like our method pointers that could be turned
into other types (this.&myMethod as Runnable), or our Swing event
handles logic using closures again for various Swing event interfaces.
So I think there could be a few areas where a project like Groovy
could benefit from MethodHandles.asInstance.
Guillaume
On Tue, Mar 29, 2011 at 00:37, John Rose <[email protected]> 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
> [email protected]
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
