Custom GuardingDynamicLinker implementations post-JEP220

Attila Szegedi attila.szegedi at
Thu Mar 5 10:42:03 UTC 2015


first of all - thanks for trying out writing your own linker! Each such attempt is a test (and if hopefully successful, then a validation) of Dynalink's architecture, and I'm glad to hear it is working for you.

Dynalink uses the "normal" service loading mechanism through java.util.ServiceLoader.load(), and I have to admit that I have not given a lot of thought to how does this change with the removal of jre/lib/ext. Wouldn't some of the same issues be encountered by other services, e.g. JDBC drivers etc?

That said, I'd intuitively think (forgive me for not stating anything with certainty, I'm just thinking this aloud as this is new to me as well, and I haven't tried any approach myself so far) that placing your linker on the boot class path with -Xbootclasspath/p:<path-to-your-jar> should work. It'd be weird if it didn't see Dynalink classes when it's in the boot class path. Again - how are other JDK elements using ServiceLoader, most notably JDBC supposed to work then?

A long term escape route is to have Dynalink become publicly supported OpenJDK API. That's an effort I should be driving, but it admittedly didn't have chance to bubble up to the top of my task pile for quite long time. I was also admittedly a bit reluctant about it as I wanted to give it more time to solidify; once it's a public API, changing it will become much harder. In any case, I wouldn't expect it to become a public API for Java 9, there simply isn't time enough for that.

For historical perspective, we initially put Dynalink into Nashorn because it seemed like the best solution for a higher-level semantics linking for a dynamic language. (Well, I'm biased as I'm its author, but the rest of the team seems to share the opinion after three years of using it.) Yes, the package-renamed Dynalink retains its (package-renamed) autodiscovery capabilities, but that's mostly incidental :-(

One somewhat unorthodox solution that might work for you depending on your needs would be to isolate Nashorn source code out of OpenJDK, observing its license (GPLv2 with classpath exception). You could take the source of everything under jdk.nashorn.* package, rename them to your own package, change all the references to jdk.internal.dynalink to org.dynalang.dynalink and all references to to org.objectweb.asm. Then you end up with a JavaScript runtime that's basically Nashorn, but works with the GitHub version of Dynalink (and the OW2 version of ASM). Should be a mechanical transformation, and it'd give you a multi-language interop capable JS engine until such time that I pull myself together and start shepherding the "Dynalink as supported OpenJDK API" JEP. 

Hope some of this helps.

Best Regards,

On Mar 5, 2015, at 6:14 AM, Marc Downie <marc at> wrote:

> 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> wrote:
>> 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.
>> 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.

More information about the nashorn-dev mailing list