I also believe it'd be good to have, as it's certainly going to be more efficient ultimately than what we'd generate ourselves. So having that bridge in would be a nice bonus. We could get rid of some current stuff we're doing to mimick it.
On Sun, Apr 3, 2011 at 03:13, John Rose <john.r.r...@oracle.com> wrote: > 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 > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
