On May 12, 2009, at 4:55 PM, Rémi Forax wrote: > Ok, that why I haven't found that bug before b58 because > my old tests was also on the boot class path.
Yep, I'm in the same boat; I've been living out of incremental builds and -Xbcp options for a long time. It has been a scramble for me in M3 (b58 and b59) to recover from the unforeseen effects of "hatching" out of the BCP and into a real class loader. > So this is a another workaround, put all your app on the boot class > path. Yep, for now it is. >> I don't see that there's a cleanup to be done at this point in the >> API.\ > > The VM doesn't differentiate a Java anonymous class from a standard > class, > so it seems there is no way to improve the API. Yes, unless there's a way to express the programmer's intention about the class. That's the main reason why MHs.bind is there. Or, I keep thinking there's room for a feature in the API which takes a class (maybe a concrete anonymous class) and walks up the supertype lattice looking for a supertype which is accessible to the guy doing the lookup. > >> ... it would be a long stretch to call these conversions subtype >> relations. >> > > The downside of that is that the only way to implement Neal's closure > type system with the current spec is to erase all Method handle type > (with convert) just after the creation of a method handle. Yes, but he was expecting to do that anyway. I've had some interesting 1-1 conversations with Neal lately about MHs and closures; the semantic gap is not as bad as I thought it might be. > About the slow down effect, It can be removed by allowing the two way > (John's one and Fredrik's one) to call a method handle: > MethodHandle.invoke() that performs a single pointer check and > MethodHandle.apply() that performs a less restrictive/more expensive > check. Well, that's what MHs.invoke is for! See the latest javadoc, which I just posted: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-b59/ (And, I've taken some pains to make it reasonably fast.) -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
