SAM types are overkill for my use (partially because I never quite grokked what they were), but I do use asInstance to provide a bridge between my (MethodHandle-centric) programming language impl and "old school" functional impls. Also, I use it to feed method handles (with their arguments fully curried) onto java.util.concurrent.Executor instances. So I would really be sad if it went away, because it would mean hand-rolling all those conversion points.
~~ Robert. On Sat, Apr 2, 2011 at 6:13 PM, John Rose <[email protected]> wrote: > There's been a good discussion about the "asInstance" API in JSR 292. > Please chime in (or start a thread here) if you have any further thoughts. > http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-March/002710.html > Current API proposed for adjustment or removal: > > http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandles.html#asInstance(java.lang.invoke.MethodHandle,%20java.lang.Class) > Bottom line question: Should we do an 80% first effort in JDK 7, or put > proxy generation off for later? > Best wishes, > -- John > P.S. The JSR 292 package rename is complete in JDK7 b136. > Docs (derived from those currently under Public Review) are here: > http://download.java.net/jdk7/docs/api/java/lang/invoke/package-summary.html > Begin forwarded message: > From: John Rose <[email protected]> > Date: March 28, 2011 3:37:46 PM PDT > To: Da Vinci Machine Project <[email protected]> > Subject: who needs asInstance... > Reply-To: Da Vinci Machine Project <[email protected]> > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
