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

Martin Lehmann martin.lehmann at gmx.de
Wed Sep 7 09:50:50 UTC 2016

Hi Alan,

thanks for your answers.

Sorry for the late answer but I meanwhile uploaded the example to Github:

LayerBuilder does the startup of Jigsaw layers: 
ModuleCaller does the reflective calls to other modules: 

mod.x_bottom/middle/top have been mentioned already.
The other modules are similar to mod.x*: mod.y* is for class derivation
across module/layer boundaries. mod.z* is an example for delegation across
module/layer boundaries.

mod.layer for my own tree structure of layers:
It is constructed from a JSON file and each layer node in the tree has a
name, keeps references to parent / child nodes in the tree.. and also a
reference to the Jigsaw layer.

PS: Do I understand correctly, that a Jigsaw layer can see its parent layer,
but there is no API to retrieve its children layers? 
If not, is there any way to globally retrieve "all layers" for iteration? I
think, that I once saw a similar question on this mailing list but cannot
find the mail thread right now...

> > 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.

Yes, please consider to add that functionality. Will also help in regression
tests (as Layer.toString() will print a different hashCode every time, so
result containing the layer info will differ).

> > 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).

Ok, thanks.

> > On the other hand, my starter module mod.main is in the topmost boot
> > Via reflection, it can see and call anything from there in any module
> > 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? 

No, I am not using Class.forName. Instead I am using layer.findLoader. See
line #64 here:

> Alternatively maybe one of the types in modules defined to these layers is
leaking back to code in mod.main.

Hm, no. There is no relationship from any of the mod.x* modules to mod.main,
see here 
All is done via reflection.

> >
> > If readability and accessibility are given either statically in
> > 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?
> > 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
> > something?
> No, that is different design.

I think I am missing your point here... Do you mean "No, that would a
different design and is (currently) not supported/available". Or do you
mean: "Well, yes, there is a different API for that". (If the latter, which
Guess, it's not supported for now.

> > 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.
> > children of the same parent layer)? Or to cousins or ... ;-)
> > Is it needed to use the parentLayer's configuration? Or is there any way
> > 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.

Yep, I can confirm that. Works perfect :-) 

> > 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
> > 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
> >      error: module  reads package pkgx from both mod.x_top and
> >      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
> > prevents compile success. Let me emphasize that I have no reads static
> > relationship to the mod.x* modules *anywhere* (not in code, not via
> > 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.

Ok, thanks. I can confirm, that this compile issue is still there with b134.

More information about the jigsaw-dev mailing list