I find this a difficult question because I haven't had chance to experiment enough with them for my application; multiple dispatch. asInterface is potentially useful but I need to trial different approaches, which is currently work in progress. Therefore my answer is include asInterface if it is:
a) Easy to do b) Doesn't prevent anything Project Lambda might want to do (and preferably be a step along the way) As an aside, I think it is great that you ask these questions and consider the responses from the wider community. Cheers, -- Howard. On 29 March 2011 09:37, 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 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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- -- Howard. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
