who needs asInstance...

[Ben Evans]

Hi John,

To my mind, this is a bit of a foxy one.

As I've been working more with MHs and indy, I've become convinced that the
set of use cases is actually much larger than I first thought (although this
may be down to an initial lack of imagination on my part).

So, on the one hand, I feel that there will be potentially a larger pool of
people using this tech in JDK 7 - and that making their lives easier is a
good thing. I think if asInstance() is present, people will make use of it.

On the other, I am very strongly against the idea of having two related, but
slightly different conversions mechanisms in this space. Until JDK 8,
efforts in this space could basically amount to either second-guessing
Project Lambda or producing asInstance() as an API which has "planned
deprecation". Both of those are seriously suboptimal.

That's how I see the trade-off between doing something in 7 vs waiting for
Lambda.

As a tie-breaker:

In general, 292 is largely a language-agnostic spec. However, asInstance()
seems, to me, to be an API designed to help Java programs specifically, by
converting a method handle (which I see as more-or-less a language-agnostic
function pointer) to Java's conception of a function-like type. As there's
no explicit language-level support for Java elsewhere (including a lack of a
direct way to generate an indy bytecode from Java) this seems a bit odd to
me.

So I think that on balance, removing the API for now makes more sense.
Perhaps publish the source code for the method as an example, to allow
framework builders and others who may need to wire this up by hand to do so
in the interim.

Thanks,

Ben

On Mon, Mar 28, 2011 at 11: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 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
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110329/26487447/attachment-0001.html