On 05/23/18 19:04, Alan Bateman wrote:
On 23/05/2018 16:39, Peter Levart wrote:
I thought so. This is what debugger told be me about TCCL (debugger
calls .toString() on it by default):
ClassRealm[plugin>com.marand.misc:misc-mojo-git:1.24, parent:
jdk.internal.loader.ClassLoaders$AppClassLoader@1de0aca6]
But now that you asked specifically, I also checked the instance and
evaluated .getParent() on it and got null ?! toString is a damn liar!
It seems that Maven class loaders don't follow standard delegation
model and so JDK can't climb the chain. Sorry for not checking this
before. There's nothing JDK can do about it, I belive.
Which Maven plugin is this and is the latest version? The work to get
Maven working with JDK 9 got started in 2015 so I'm surprised that
there are still issues.
It's not an official plugin. And it seems that the Maven container is to
blame, not the plugin. The nonstandard ClassLoader is supplied by the
container. The plugin just uses the most direct and default API possible
to instantiate JavaScript engine:
jsEngine = new ScriptEngineManager().getEngineByName("JavaScript");
It is the environment the plugin is executing in that doesn't play well
with how system service providers are located from JDK 9 on - namely,
the nonstandard ClassLoader that delegates to system class loader, but
does not express this also in the .getParent() result. I don't know why
Maven choose this, but closer inspection reveals that its ClassLoader
does have a "parent", but it keeps it in its own field called
"parentClassLoader" and doesn't return it from .getParent(). There must
be a reason for this, but I don't know that it is.
Do other parts of the JDK also use TCCL to bootstrap service lookup by
default? Isn't it unusual that ScriptEngineManager uses TCCL by default?
Regards, Peter
-Alan
