Hi Alan, thanks for your answers.
Sorry for the late answer but I meanwhile uploaded the example to Github: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e xample_layer-hierarchy mod.main: LayerBuilder does the startup of Jigsaw layers: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/LayerBuilder.java ModuleCaller does the reflective calls to other modules: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/ModuleCaller.java 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: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.layer 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 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? No, I am not using Class.forName. Instead I am using layer.findLoader. See line #64 here: https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/pkgmain/ModuleCaller.java > 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 https://github.com/accso/java9-jigsaw-examples/blob/master/jigsaw-examples/e xample_layer-hierarchy/src/mod.main/module-info.java All is done via reflection. > > > > 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. 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 one?) 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. 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. 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 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. Ok, thanks. I can confirm, that this compile issue is still there with b134.
