who needs asInstance...

[Guillaume Laforge]

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.rose at 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.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 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 at openjdk.java.net
> >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110403/618dca3d/attachment.html