Groovy with Jigsaw

[Alan Bateman]

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.