Jochen Theodorou wrote: > Charles Oliver Nutter schrieb: >> Jochen Theodorou wrote: >>> null >>> >>> and I want to call a method foo(), that means null is the receiver. But >>> instead of using the unreflected MH for foo() I use something that >>> replaces the receiver in a BMH.. so inside it will be a valid method >>> call, but will I come to this point even? >> It appears to work fine in my test: >> >> $ $JAVA_HOME/bin/java -cp dist/InvokeDynamicTests.jar -XX:+InvokeDynamic >> com.sun.dynamic.test.DynamicAgainstNull >> reporting bootstrap method to JVM: >> bootstrap:(java.dyn.CallSite,java.lang.Object...)java.lang.Object >> DynCallSite: >> CallSite#9519074[target(java.lang.Object,java.lang.Integer)java.lang.Object >> => null] >> obj is null, integer is 1 >> obj is null, integer is 1 >> >> See the project here: >> >> http://kenai.com/projects/invoke-dynamic-tests > > but I cannot find com.sun.dynamic.test.DynamicAgainstNull there.
Sorry, I forgot to push. It's there now. Not much different from the other case though. >> It also occurs to me a lot of these questions could be answered by you >> trying it out yourself. Can I help you get an MLVM build going? > > it is not so much important to see what currently works and what not. It > is much more important to know if it is intended to work or not. I would > love to build a version of Groovy that uses invokedynamic and give John > then hints about performance bottle necks. But I always had the > impression that it is still too early. Also there are many things I > can't really do the way they are intended to be done yet. I could also > write tests documenting the current state, or test to state how I think > it should work (which usually means failing tests)... I think you and I and others trying it out now is important to making sure that it is useful to us later. I don't think we should expect the perfect API to fall out of the trees. Much of the basics work now, and more are coming. You and I and others can help drive the design with practical experiments. > If I have a final implementation, then how it works has to be how it > should work. Then I can use test to get a specification... But we are > far from that. I think doing this risks us arriving at a "final implementation" that only works for the languages that have experimented with it early on. I assume you would like to see invokedynamic succeed, and I don't think we want a JRuby-only invokedynamic, do we? :) > For example I know that invokevirtual will throw a NullPointerException > if the receiver is null. Afaik the invokedynamic spec says the same. Now > for MethodHandles I would expect the same too, because they are in the > end based on invokedynamic, invokespecial and invokeinterface. In case > of invokedynamic this would especially mean that a NPE is thrown even > before my bootstrap method has a chance. Now, how should I know if the > current implementation is even doing the correct thing here? It does not appear to work that way at present, and of course the EDR was a draft. You and I and others have a unique opportunity here to directly influence it in the right direction for our respective languages. Try my example. FWIW, it took all of a day to wire invokedynamic into JRuby, once the bug I mentioned was resolved. There's much more iterative improvement yet to be done, but that can come as the API solidifies. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
