Am 11.09.2015 14:47, schrieb Alan Bateman:
[...]
It's always been possible to configure the system class loader to be
something else. So I'm curious what you do if it is a URLClassLoader,
are you just looking for the class path?
Then it would not work. But since the cases for @Grab have not been
cases in which you normally do that, there was almost always the chance
to do this in practice. Now not anymore. Normally you don't need to do
this kind of thing either. There is for example GroovyRootLoader, which
we use to load the Groovy runtime, which is an URLClassLoader and can be
used... only in some cases like some jdbc drivers you need a higher
loader and that's where the system class loader was used in the past.
What is the alternative?
And somebody has to explain to me why this is supposed to be different
for Nashorn. I would imagine it is even worse there, since Nashorn can
see internal APIs, that are hidden to others and since it is part of
the JDK.
Nashorn is updated in the EA builds to work with modules, it is spinning
dynamic modules at run-time. I think it requires building up examples of
real needs before thinking about an API here.
My thought experiment is the following...
Have module A, with internal API in a.internal and public stuff in
a.public. Furthermore A is written in Groovy. Let us say there is a
public static method a.internal.BadClass#badMethod(), then any Groovy
program can do the following: a.internal.BadClass.badMethod(). And that
is because the method call will be done from Groovy. For A to be working
there has to be a Groovy module which is allowed to access the internal
API, since otherwise the classes there won't work.
But maybe this question should go to the expert group instead?
bye Jochen
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
