John Rose wrote: > On Apr 15, 2008, at 8:17 AM, Charles Oliver Nutter wrote: >> >> I'm also interested in what we can do to help languages on pre-JDK7 >> >> JVMs, since the vast majority of real users of JRuby (for example) could >> >> use some real help now. But I will look at your patches and try to >> >> formulate some strategy myself as well... >> > > This stuff would be merely academic if there were no story for how old > JVMs play with the new features. So for me a big part of the puzzle of > method handles has been to build in a backward-compatibility story that > lets them be emulated on old platforms, with efficiency no less than > (say) your JRuby invokers. > > Then it becomes feasible to have the dynlang backend perform a JVM > version check at boot-up, and choose better vs. best implementations. > > And I hope a similar compatibility story can be found for the anonoymous > class loader.
The general concept I've had for backward-compatible invokers would be to provide a way for consumers to plug in their own argument and exception-mapping logic. So where JRuby, say, takes the input arguments to a given "call" on DynamicMethod and translates them into pre and post-call logic, exception-handling and finally wrappers, and the eventual construction of an argument list for the target method, the more generic and generally-useful version would allow this behavior to be customized, either by passing in an implementation of "argument mapping", etc, or by providing template code that could be rewritten by the handle generator. This same logic is going to be needed for most languages that have non-standard (i.e. non-Java) mechanisms for collecting methods together into a type-representing bundle, and with so many pre-JDK7 installations out there, having a backward compatible solution is a must. And yay, I think I finally got the hg patchset to apply. Onward to experimentation! - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
