Groovy with Jigsaw

[Jochen Theodorou]

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/