Custom GuardingDynamicLinker implementations post-JEP220

[Marc Downie]

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 <
sundararajan.athijegannathan at oracle.com> 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.
>>
>
>