JEP 276: Dynamic Linking of Language-Defined Object Models

[Attila Szegedi]

On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:

> 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?

Sure, here’s how Nashorn does it:

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92 <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/f93753325c7b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java#l92>

You’ll notice that Nashorn has a total of 10 linkers - they’re modularized per purpose. 

Some of them are internal, that is, they only operate on call sites within Nashorn:
- NashornPrimitiveLinker deals with linking java.lang.Number, java.lang.Boolean, and java.lang.String objects as if they were JS number, boolean, and string primitive values.
- BrowserJSObjectLinker that allows linking of netscape.javascript.JSObject objects (should they somehow be passed to Nashorn)
- NashornStaticClassLinker links the NEW operation to enable the “new java.lang.Runnable() { … }” anonymous-class style creation of adapters for Java interfaces.
- NashornBottomLinker deals with linking missing properties on POJOs as well as linking operations on null, mostly supplying language-specific error-raising behavior.
- NashornBeansLinker is a bit weird one, as it mostly delegates to ordinary BeansLinker, but it deals with some odds and ends, namely allowing @FunctionalInterface objects to be linked as JS callables and smoothing over the fact that internally we don’t always use java.lang.String for representing strings.
- ReflectionCheckLinker is an interesting beastie as it doesn’t link anything itself, but can prevent linking Java reflective operations (they are specifically disallowed in Nashorn; this is policy due to the fact Nashorn is part of the JDK and we’d rather conservatively take that functionality away from JS programs than deal with a security risk). 

Then we have those that could be exported:
- NashornLinker obviously, as it’s the primary linker for all native JS objects, as well as JSObject linker as it’s the primary linker for exported JS objects
- BoundCallableLinker that is a nice example of how you provide linking by delegation; it provides linking of bound callables by delegating to the linker for the underlying unbound callable, and then re-binding the result of that linkage
- JavaSuperAdapterLinker is another delegating example working similarly to the previous one; this one handles the Nashorn’s feature for allowing super-calls to Java objects from adapters

The first 8 (prioritized) linkers all implement the TypeBasedGuardingDynamicLinker interface, meaning the factory will internally compose them into a fast (constant time) dispatch-by-receiver-type CompositeTypeBasedGuardingDynamicLinker instance; you could have any number of those without impacting the linking performance (not that finding the right linker is the slow operation usually).

Attila.