Custom GuardingDynamicLinker implementations post-JEP220

[Marc Downie]

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.