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/
