On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackd...@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.
