Custom GuardingDynamicLinker implementations post-JEP220 (original) (raw)

Marc Downie marc at openendedgroup.com
Wed Mar 4 22:56:09 UTC 2015

Dear all,

I've been adding my own GuardingDynamicLinker implementation to the linkers used by Nashorn to modify how Nashorn thinks about about certain classes / JVM languages. This has been working absolutely splendidly, and the Dynalink core of Nashorn has been wonderfully useful. In fact all previous questions I've had on list about how to customize the appearance of Java to Javascript (to the same extent that I can do with Jython and JRuby) can really be answered with "write a custom linker".

Currently, I cause Nashorn's call to AutoDiscovery to see my linker implementation by having it in a .jar with a META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker entry and placing that .jar in lib/ext. But with the abandonment of lib/ext in JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn doesn't see my linker if I place it later in the classloader tree, and my linker can't see its super-interface (GuardingDynamicLinker) if it's on the bootclasspath.

I realize that I've committed the sin of writing 'jdk.internal', but reading the source of Bootstrap and AutoDiscovery the intent is clear: to allow additional language runtimes to coexist inside the same linker ecosystem. A design bug?

Any suggestions, example code, or an escape route, welcome.

Marc.

More information about the nashorn-dev mailing list