On 26/08/2019 22:37, Stephan Herrmann wrote:
:
If the above list is correct (complete?), some questions remain:
- What should happen when (2) declares a set of packages that differs
from what scanning would result in? Can (2), e.g., be used to hide a
package?
The ModulePackages attribute would win in that case, at least in the JDK
implementation. The likely implications would be compilation errors or
NoClassDefFoundErrors at run-time because the classes in that package
would not be visible.
- Is it possible to export/open a package that has no .class in it?
According to JLS: no!
- does this imply non-java packages are always encapsulated?
I think you are looking for JLS 7.7.2.
At run-time, a non-class resource will be encapsulated if the
corresponding package is not open to other modules.
- Can any package from (4) contribute to a conflict viz-a-viz JLS
7.4.3? Due to lack of export we may have to say: a non-java package in
the current module vs. an exported java package from a read module, is
that a conflict? Who should signal the conflict, if any?
Not at compile-time.
At run-time you cannot map two modules containing the same package to
the same class loader. In your example, it sounds like you have two
explicit modules with package "about_files" so they conflict when mapped
to the application class loader.
:
- What is the rationale for the fact that adding module-info may
result in more packages (due to difference (3) vs. (4))?
Non-class resources in explicit modules can be encapsulated. Resources
in automatic modules cannot be encapsulated. The reason that the non
class resources don't contribute to the set of packages in an automatic
module is to maximize the potential for use of existing JAR files as
modules. In your "about_files" case then I assume the two JAR files
would have worked as automatic modules.
- Where can we read the difference between what JLS allows (including
concealed packages of the same name in different modules) vs. what the
boot layer implementation accepts? Should we assume that the boot
layer behaves as if created by
ModuleLayer.defineModulesWithOneLoader()? The latter's javadoc is the
only spec I could find mentioning the problem of "overlapping
packages", but clearly that method cannot create the boot layer due to
the restriction regarding java.base.
The boot layer is special, think ModuleLayer::defineModules with a
function that maps the modules to the built-in class loaders but all the
restrictions of defineModulesWithOneLoader. You are right that the
paragraph on the boot layer in the ModuleLayer could say more on this.
- the same javadoc speaks only of unnamed / named modules. But what
happens in an automatic module? Isn't the javadoc saying that an
automatic (=named) module may consider a non-java resource to be in a
package, while according to (3) automatic modules have no non-java
packages?
I don't see an issue here as these resources are not in one of the
module's packages and therefore cannot be encapsulated.
-Alan
