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
