Charles Oliver Nutter schrieb: > 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.
ok, now I see the test... but that is no test with the receiver being null >>> 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. sure, that is a different line though. I plan to spend some time with this after the next groovy release... which is as soon as some strange things in Grails are fixed, because we are not yet sure if they are Grails bugs, or Groovy 1.6 bugs I am only saying that specifying by something that is very likely to change very much is not useful. Helping to develop it is something else. >> 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. I expect that to be a little more difficult in Groovy, because we are more in touch with the bytecode. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
