Custom GuardingDynamicLinker implementations post-JEP220

A. Sundararajan sundararajan.athijegannathan at
Thu Mar 5 04:10:20 UTC 2015

Linker auto discovery is a feature inherited from the dynalink project -

Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as 
dynalink is an implementation detail. Auto discovery/pluggable linker is 
not enabled for nashorn.  In addition to using an internal 
implementation class - which may be changed without notice - please note 
that your code using jdk.internal.* dynalink class won't run when there 
is security manager present. jdk.internal.* is declared to be security 
sensitive package in the Java platform default security configuration.


Marc Downie wrote:
> 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