On 18.10.2015 18:19, Attila Szegedi wrote:
[...]
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.
not true anymore, yes, now I know ;)
[...]
* 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.
Ok, I get it, the JEP is mostly to move the internal dynalink into a
public package and maybe adapt in some ways to make it more usable for
other languages.
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.
since it is dynalink there is I guess only one master linker in the end.
Can you point me to some code showing how the composition of linkers is
done to refresh my memory on that?
bye blackdrag
