Groovy with Jigsaw

[Jochen Theodorou]

Hi,

we are currently investigating problems Groovy has with Jigsaw. A lot 
changed with jigsaw, and since Groovy does often not use standard 
methods, a lot fails.

But first I would like to ask something that I haven't seen covered in 
http://openjdk.java.net/projects/jigsaw/quick-start or 
http://openjdk.java.net/projects/jigsaw/spec/sotms/ Maybe I did not see 
it, since it is late here. I hope the questions should not better have 
gone to the expert group comment list. It was not fully clear to me 
where goes what. Anyway...

As far as I understood a classloader can have a N modules plus the 
unnamed module. I assume a the children of a classloader do not 
automatically share modules (or not at all?) with their children.
Do assume right in that there is no way to create a module at runtime?

Next question is about runtime generated classes. And I mean here 
classes generated by user code at runtime, as well as proxies, code for 
reflection and invokedynamic and all the other bytecode generating 
facilities. Will they all go into the unnamed module?

Assuming they go there (how else can you choose from those N modules), 
what access rights to the modules will they have? I assume to everything 
that is exported, and for that it does not matter if it is the same 
class loader or a parent or any other loader.

I further assume you can load a module at runtime... by for example 
using URLClassLoader. Now let us say there is a classloader for module 
A, which exports some packages to module B. Must module B then be loaded 
in the same classloader (or a parent) as A? If a child loader can load B 
and allow access according to the exports rules. What happens if 
multiple children each have their own B, and maybe those B are totally 
unrelated to each other? I assume this is possible.

Now a more practical one... In Groovy we have code like this:

         try {
             AccessController.doPrivileged(new PrivilegedAction() {
                 public Object run() {
                     c.setAccessible(true);
                     return null;
                 }
             });
         }
         catch (SecurityException e) {
             // IGNORE
         }

which is code supposed to "check" if we can access the class member or 
if any security manager will disallow this. In this case the method 
becomes unavailable for invocation... Now jigsaw changes do make the 
setAccessible method also throws 
java.lang.reflect.InaccessibleObjectException. What is the suggested way 
to handle this for code that has to be also compatible to pre JDK9 code? 
catch RuntimeException, check the class name and rethrow if the name 
does not fit?

And then a question probably a bit more complicated...

Groovy uses reflection/runtime generated classes/invokedynamic to invoke 
methods. That means the method invocation point (for reflection, the 
class that calls the invoke method) is most often in the Groovy runtime. 
And even if Groovy would define its own module, those runtime generated 
classes would not be in the same module (or is there a way for this?) 
Now assume somebody wrote this class in Groovy:

/* code without sense following */
class MyFactory {
   public Factory getFactory() {return new FactoryImpl()}
}
interface Factory{String foo()}
class FactoryImpl implements Factory{
   String foo() { return internal()+"foo" }
   String internal() {"Factory"}
}

and let us assume MyFactory and Factory are in a package, which is 
exported, FactoryImpl not. Now... since Groovy is currently in no module 
and since it needs to use reflection to execute the internal() method 
call here, does this mean the call will fail, because the object is 
inaccessible? Actually I assume we would not even see the method.

If that assumption is right, does this means every application that uses 
modules and is at least partially written in Groovy, has to export each 
and every package to Groovy, in order to allow it to do method calls? 
That is assuming Groovy has a module by then. Without it I assume it 
cannot be made.

Well... enough for now, further questions will surely develop later on.

bye Jochen Theodorou

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/