Linker auto discovery is a feature inherited from the dynalink project -
https://github.com/szegedi/dynalink
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.
Thanks,
-Sundar
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.
