JEP 276: Dynamic Linking of Language-Defined Object Models

[Jochen Theodorou]

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