Custom GuardingDynamicLinker implementations post-JEP220
attila.szegedi at oracle.com
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 :-(
Hope some of this helps.
On Mar 5, 2015, at 6:14 AM, Marc Downie <marc at openendedgroup.com> wrote:
> So, to summarize, the intention is that Nashorn will no longer participate
> in a Dynalink powered multi-language interop or linker plugins? How
> 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 -
>> 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.
>> Marc Downie wrote:
>>> Dear all,
>>> I've been adding my own GuardingDynamicLinker implementation to the
>>> 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
>>> questions I've had on list about how to customize the appearance of Java
>>> 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
>>> 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
>>> 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
>>> 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.
More information about the nashorn-dev