> On Oct 18, 2015, at 10:49 AM, Jochen Theodorou <blackd...@gmx.org> wrote:
>
> On 17.10.2015 13:30, Martijn Verburg wrote:
>> This looks very, very promising. Would it help to get the language
>> maintainers of the most popular scripting/dynamic JVM languages involved
>> ASAP? Happy to contact Groovy, Clojure, Scala, JRuby folks (although I
>> suspect many of them are on this list).
>
> still easy to miss something like this ;)
>
> But I can give some comments for Groovy on this already. As I understand it,
> this JEP is mostly for calls from Java on objects from other languages.
I would say that understanding is incomplete. It is used to call from any
language to any language. You can certainly use it to call from Java to another
language, as well as to do dynamic calls within a single language, and across
two different languages, neither of them necessarily being Java.
> I have basically only main points:
>
> * Invokedynamic (like invokeinterface and invokevirtual) does not like calls
> with null as receiver, quitting the call right away with a NPE.
This is fortunately not true, and Nashorn can show you that it isn’t. Launch it
with:
$JAVA_HOME/bin/jjs -doe -J-XX:+UnlockDiagnosticVMOptions -J-XX:+ShowHiddenFrames
and type “null()” at the command prompt (Nashorn’s JS null is also Java null).
You’ll get this stack trace:
<shell>:1 TypeError: null is not a function
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
at
jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)
at
jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185)
at
jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172)
at
jdk.nashorn.internal.runtime.linker.NashornBottomLinker.linkNull(NashornBottomLinker.java:176)
at
jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:66)
at
jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124)
at
jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:154)
at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:253)
>> at
>> java.lang.invoke.LambdaForm$DMH/348100441.invokeSpecial_LLIL_L(LambdaForm$DMH:1000016)
>> at
>> java.lang.invoke.LambdaForm$BMH/827966648.reinvoke(LambdaForm$BMH:1000054)
>> at
>> java.lang.invoke.LambdaForm$MH/1273765644.exactInvoker(LambdaForm$MH:1000016)
>> at
>> java.lang.invoke.LambdaForm$MH/2013559698.linkToCallSite(LambdaForm$MH:1000011)
at
jdk.nashorn.internal.scripts.Script$Recompilation$1$\^shell\_.:program(<shell>:1)
at ...
The frames I marked with “>>” are all java.lang.invoke internals going from the
invokedynamic instruction with a null receiver, successfully dispatching into
Dynalink and then Nashorn. (The bottommost frame before the cutoff is the
invokedynamic instruction itself). It’s Nashorn that will ultimately respond to
this throwing a JavaScript-specific TypeError from within the linker.
invokedynamic doesn’t treat the first argument specially (in this one sense
it’s more like invokestatic).
> But languages may allow for calls on null. That again means some kind of
> dummy receiver is required, if this is supposed to work. Then of course, if
> you want to allow calls on null, every call would have to go through the
> runtime in the end, thus I suspect this will be out of scope for this JEP.
>
> * Another part is the lookup of calls itself. To me the JEP is not fully
> clear here. Sure, there is a service for this, but is every call checked?
> That may slow down normal compilation for Java. The JEP speaks of methods
> provided beyond what Java offers - but what about methods replacing normal
> Java methods?
JEP 276 does not concern itself with any aspect of a compilation. It concerns
itself with what happens at run time when an invokedynamic instructions needs
to be linked.
It is the job of the language-specific linkers to resolve the method handle to
be linked. JEP 276 specifies one built-in linker named BeansLinker which
provides the “usual” operational semantics for POJOs that can be used
standalone or composed with other linkers (Nashorn obviously composes it with
its own linkers so it can link both POJOs and native JS objects at any call
site). BeansLinker looks up method handles mostly through unreflection. I’m not
sure what do you mean by “checked” either - only public methods on publicly
accessible classes are considered at this time.
Hope this clarifies few things.
Attila.
>
> Btw, one part that would make me very happy, is an official API, that allows
> some control of phases of the Java compiler as well as make missing classes
> programatically known to the compiler without requiring the java compiler to
> write those out as well. And that especially because I assume that jigsaw
> will put all the api needed for this into hiding by modules.
>
> bye Jochen Theodorou
>
