Jeroen Frijters a écrit : > [EMAIL PROTECTED] wrote: > >> If the type descriptor of the invocation is of the form (TUV...)W, then >> type[0] is T. >> > > Hmm. I feel that I'm missing something very essential or that we are > completely miscommunicating. > > >From your blog entry on Method Handles > >(http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell) I understand > >that for a direct method handle the receiver type is in fact > >MethodType.parameterType()[0]. > > In your blog you wrote: > >> In pseudo-code: >> >> MHD h1 = H(Object.equals); >> > [...] > >> assert h1.type() == SIG[(Object,Object)boolean]; >> > > So far, this makes perfect sense to me. > > Now, I assume that it should be possible to pass a direct method handle to > CallSite.setTarget(), right? > > If this is true then how can I reconcile that with your statement above that > the receiver type is not in MethodType.parameterType()[0]? > > >>> I assume it's the type that the verifier computed for the receiver >>> object on the stack, but I would like to be sure. >>> >> No, that type is always Object, and implicitly assumed. >> > > It seems like a shame to throw away type information. It means that somewhere > down the line a downcast is likely needed, for HotSpot this may not be a big > deal because it can inline the code and remove the cast again, but for more > static compilers it results in a needless cast. > Hi jeroen, in my opinion, the spec implicitly says that the type of the target method handle is different from the type of the callsite : callsite.getTarget().type() != classiste.type()
As you said the type of the target method handle embeds the receiver type, and as john said the type of the site doesn't include the receiver type. I don't like that mismatch, because it's confusing and as you said, the receiver type processed by the compiler is forgotten and it can be usefull. I don't see why the spec implictly requires that the receiver type must be java.lang.Object. > Another question that may help clarify things for me: Is a design goal to > allow invokedynamic to link directly (i.e. without an adapter method) to > existing Java methods? > yes > This also brings up the issue that arguably method handles passed to > CallSite.setTarget() should be allowed to be have covariant return and > contravariant argument types. > In my opinion, it's better to change the spec to say that the type of the callsite must be the same that the type of the target. > Thanks, > Jeroen > cheers, Jeroen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
