Non-java resources creating split-package problems?

[Alan Bateman]

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