On 10/09/2015 23:40, Jochen Theodorou wrote:
:
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.
The "Class loaders" section in the SOTMS document provides a good
summary of the proposed design. The current builds implement this so
that a module is defined to a class loader. You can't some types in a
module defined by one class loader and other types in the same module
defined by a different class loader (how would package private access
work for example).
I'm sure there will be lots of discussion about class loaders in the JSR.
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?
In the proposed design there is a concept of layers of modules. The
EA/prototype builds have API support for this and you'll find tests in
the jdk repo that exercise this API to create configurations and
instantiate them as modules in the run-time.
Supporting dynamic languages and creating dynamic modules is very much
an advanced topic at this time and there isn't support in the exported
API for this. There is of course low-level support in the implementation
and you'll find that Proxy and a few other areas that spin classes at
run-time are using it in the current builds.
At this time, if you are spinning classes the same package/loader of
existing modules then those generated classes will be members of the
module. If you are spinning classes into new packages or different class
loaders that don't have any modules defined to them then they will be in
that loader's 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.
Assuming they created in an unnamed module then it's as per the "Unnamed
modules" section of the document.
I see you have other questions about Groovy being a man-in-the-middle. I
don't have time to reply to that now, others have have cycles to engage
on that topic.
-Alan.
