Custom GuardingDynamicLinker implementations post-JEP220

[Marc Downie]

Attila,

1. Many thanks for your constructive email.

2. To my eyes Dynalink, or at least something a lot like it, is an
important part of the future of the JVM --- make it a JEP ! The alternative
— an ecosystem of dynamic languages using Dynalink that don't interop with
Nashorn, also using Dynalink, is daft.

3. Your intuition is correct --- this is important enough to me that I'll
be, reluctantly, building and "shipping" my own Nashorn.

4. bootclasspath/a or /p on 8 doesn't work right now because nashorn.jar is
itself a lib/ext (and bootclasspath is before lib/ext). Bootstrap's static
initializer says:

// Linkers for any additional language runtimes deployed alongside
Nashorn will be picked up by the factory.

factory.setClassLoader(Bootstrap.class.getClassLoader())

which resolves to the Extension classloader in 8 (and thus allows linkers
in lib/ext) and the system ClassLoader in 9 (and thus allows nothing of the
sort). Obviously my "pull request" for this would be to wrap that line in
an Option that can switch to using the ThreadContext ClassLoader instead
(which is the default behavior). Otherwise, you should probably modify that
suggestive comment, since in post JEP 220 there doesn't seem to be an
"alongside" to deploy language runtimes to.

many thanks,

Marc.



On Thu, Mar 5, 2015 at 4:42 AM, Attila Szegedi <attila.szegedi at oracle.com>
wrote:

> Hi,
>
> 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 jdk.internal.org.objectweb.asm 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,
>   Attila.
>
> 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
> > 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.
> >>>
> >>
> >>
>
>