A few questions on layers ... and a compile problem with split-package caused by automatic module

[Alan Bateman]

On 05/09/2016 18:26, Martin Lehmann wrote:

> :
>
>
> Question 1)  Is there any way to give a layer a name or an ID? My current
> workaround is to put my layers to a map which do the name <-> layer-instance
> mapping which is not nice. Please consider to allow layer names, thanks.
Layers don't have names. It's come up once or twice in the context of 
diagnosability as it's potentially useful to have in stack traces.  I 
think TBD as to whether to do this or not, esp. given the number of 
fields that are now going into the stack trace element.

> :
>
> What's the visibility of modules (i.e. their classes) along the layer
> hierarchy / relationships? I had expected that a module (i.e. its classes)
> can only see modules (i.e. classes) in the same layer or in its parent or in
> any of its parent layers.
> I have tried this with a class hierarchy where a class in "bottom" is
> derived from a super class in "middle" which is again derived from a super
> class in "top". For that readability is needed from bottom -> middle -> top.
> Works as expected.
When using the Layer defineModulesWithXXX methods then the class loader 
delegation supports the readability graph. So from a module then you 
will be able to "see" any of the types in the packages exported by the 
modules that is reads. In addition, I note in your example that you've 
specified the system class loader as the parent class loader. This means 
that you can "see" types that are visible via the system class loader 
too (assuming no overlapping packages in the graph of modules).


> On the other hand, my starter module mod.main is in the topmost boot layer.
> Via reflection, it can see and call anything from there in any module (i.e.
> also classes in "lower layers", i.e. in top, middle and bottom).
Are you using Class.forName and specifying the class loader for top, 
middle or bottom? Alternatively maybe one of the types in modules 
defined to these layers is leaking back to code in mod.main.

>
> If readability and accessibility are given either statically in module-infos
> or dynamically at runtime, then are there any constraints of what can be
> seen / called?
If you are using the 3-arg Class.forName then this allows you to get a 
reference to any type in any module.


> :
>
>
> Question 3)
> Is there any way to add / delete modules from a given configuration?  For
> now I used the 2 code lines above (***) to use the parent layer's
> configuration when creating a new configuration for a new layer.
> I have not found any API to add / delete modules "on the fly". Did I miss
> something?
No, that is different design.

>
>
> Question 4)
> With using (***) I cannot "instantiate" a module twice along the layer
> hierarchy (which makes sense). So a module in a parent layer is already
> resolved and not added to the new layer again. Correct?
> Would it be possible to add the same module to two sibling layers (i.e. the
> children of the same parent layer)? Or to cousins or ... ;-)
> Is it needed to use the parentLayer's configuration? Or is there any way to
> create new configuration just for the new layer without "looking up the
> chain"?
No issue with overriding a module in a child layer or having two sibling 
layers with the same module. I note that in your code fragment that you 
specify "finder" as the second parameter to resolveRequires - this is 
the "after" ModuleFinder that is used when the module cannot be found by 
the "before" ModuleFinder and cannot be found in the parent layer.


> :
>
>
> Now I wanted to extend my mod.main module to parse a layer "topology" from a
> JSON file instead of hard-coding the top/middle/bottom hierarchy. I hence
> added javax.json-1.0.4.jar to amlib, added "requires javax.json;" to
> mod.main's module-info. Only by doing that I am running into these
> unexpected compile errors (checked with b127 and b132):
>      error: module  reads package pkgx from both mod.x_top and mod.x_middle
>      error: module  reads package pkgx from both mod.x_top and mod.x_bottom
>      error: module javax.json reads package pkgx from both mod.x_top and
> mod.x_middle
>      error: module javax.json reads package pkgx from both mod.x_top and
> mod.x_bottom
>      4 errors
>
> I assume that having added the automatic module javax.json , I now
> implicitely added a read-relationship to *all* other modules at compile
> time, i.e. also to mod.x* modules. With that, the split package problem now
> prevents compile success. Let me emphasize that I have no reads static
> relationship to the mod.x* modules *anywhere* (not in code, not via compiler
> command-line options).
Automatic modules read all other modules. I need to double check your 
observations because there was an issue with javac where it granted 
implied readability to all explicit modules when it should have only 
done so for automatic modules. I thought it had been fixed so needs to 
be checked.

-Alan