Chanwit Kaewkasi a écrit : > Here's link to the backport code: > > http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport > > Cheers, > > Chanwit > Currently, the backport is far from being usable :(
MethodHandle are supported if you don't have double slot arguments (double or long) in the signature. User-defined MethodHandles are not supported. There is no real support of invokedynamic, just a crude prototype. The java.dyn package is not in sync with the latest pushes of John. I have a plain text file with a plan saying how to correctly implement all these things but I haven't find the time to correctly implement it. Rémi > On Wed, May 6, 2009 at 7:52 PM, Robert Fischer > <[email protected]> wrote: > >> Where can I find documentation on the JDK 7 changes to bytecodes and the >> backport project? >> >> ~~ Robert. >> >> John Rose wrote: >> >>> On May 6, 2009, at 8:26 AM, John Cowan wrote: >>> >>> >>>> In my language, I need objects which represent Java static methods. >>>> >>> That's what method handles are for; from a JDK 7 viewpoint you are >>> asking what is the best pre-JDK7 way to emulate method handles. >>> >>> Rémi Forax has a backport project which will reweave your JDK7 >>> bytecodes into a form suitable for pre-7 JVMs. >>> >>> That pre-7 form generated by the backport uses about the same >>> expedients you are currently using. The nice thing about that is it >>> can serve as a collection point for best practices. I think grouping >>> methods in a switch is the state of the art before JDK 7. >>> >>> Depending on your schema of call types, you'll want to choose between >>> grouping call types on interface types vs. one call type per interface >>> type. Interface types can be true Java interfaces, or Java abstract >>> classes with factored default error-reporting or adapting behaviors. >>> >>> Any of those choices is usually preferable to plain reflection, >>> because the semantics of reflective invocation is very complex, as it >>> includes: >>> - wrapped individual arguments and return values >>> - wrapped varargs list >>> - wrapped exceptions >>> - per-call access checks with associated exceptions >>> >>> Also, reflection does not support the semantics of invokespecial. And >>> there may be a footprint cost, as reflective objects are not mere >>> invocation capabilities (like method handles). They carry extra >>> baggage around to support symbol table queries such as annotations, >>> throws clauses, and Java generic signatures. >>> >>> I hope this helps. >>> -- John >>> >>> >> -- >> ~~ Robert Fischer. >> Grails Training http://GroovyMag.com/training >> Smokejumper Consulting http://SmokejumperIT.com >> Enfranchised Mind Blog http://EnfranchisedMind.com/blog >> >> Check out my book, "Grails Persistence with GORM and GSQL"! >> http://www.smokejumperit.com/redirect.html >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
