On Mar 28, 2011, at 4:43 PM, Howard Lovatt wrote: > a) Easy to do
Yes, it's easy to do. (Done now with Proxy, in a poor-man's way, and simple to improve upon.) > b) Doesn't prevent anything Project Lambda might want to do (and > preferably be a step along the way) That's the issue. Lambda must come up with their own fully-defined concept of SAM, and will then (probably) want to define a conversion routine that interoperates with JSR 292. Perhaps something like java.lang.Class.asSAMInstance(mh); nobody knows at this point. What we do know is that (a) JSR 292 can only define things at the JVM level, and (b) Lambda is likely to need something different (notably, bridge methods driven by complex language-specific rules). Putting a conversion into java.lang.invoke.MethodHandleProxies doesn't strictly prevent doing something Lambda-like in java.lang.Class, but we want to avoid having two things (one from 292 and one from Lambda) which do *almost* the same thing. If there's no clear difference, we introduce a tricky dilemma to users; the risk is that they will choose at random and then have to fix code that acts surprisingly. I think clear naming and clear definitions will address this risk, but unless someone is going to actually use the JVM-level thing in the JDK7 (Java SE 7) time frame, it's a little bit safer to punt for 8. Of course, there are risks with that too. Hence my questions to the community. > As an aside, I think it is great that you ask these questions and > consider the responses from the wider community. I'm glad! -- John > 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
