<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 20, 2009, at 2:28 AM, Rémi Forax wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">MethodHandle supports was almost ready before John changes the format of<span class="Apple-converted-space"> </span></font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">MethodType</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">(to add varargs bits)</font></p> </blockquote></div><br><div>Aghh! Stub out the varargs bits if you want; after using them a little I'm beginning to think they are not worth the trouble. Sorry for the thrash.</div><div><br></div><div>The key insight, I think, is that method handles are pure JVM-level behavior, without attached intentions like "I have an optional argument" or "I am a field setter"; that sort of information properly belongs in the (mangled) invocation name of invokedynamic, not wedged into the method handle or its type. The varargs bit in MethodType, although temptingly connected to the varargs bit in JVM methods, doesn't really help things fit together. In particular, there is no way (that I can see) to issue a true varargs call from bytecode. Given the following invokevirtual, where does the varargs part appear?</div><div><br></div><div> invokevirtual java/dyn/MethodHandle, invoke, ([Ljava/lang/Object;)V</div><div><br></div><div>-- John</div></body></html>