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

Reply via email to