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.r...@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 previousl! y 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@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
