So, to summarize, the intention is that Nashorn will no longer participate in a Dynalink powered multi-language interop or linker plugins? How disappointing!
best, Marc. On Wed, Mar 4, 2015 at 10:10 PM, A. Sundararajan < [email protected]> wrote: > > 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. >> > >
