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.
