Non-java resources creating split-package problems?

[Alan Bateman]

On 24/08/2019 21:11, Stephan Herrmann wrote:
> Hi,
>
> back then when working on our compiler I didn't pay much attention to 
> non-Java resources, as JLS doesn't make any mention of them.
>
> Recently, however, we found that plain text files in a modular jar can 
> well cause the VM to refuse starting, 
I think you are mainly asking how to determine the set of packages in a 
(named) module.

Automatic modules are straight-forward. The set of packages is 
determined from the non-directory entries in the JAR file that end in 
".class". The API docs for ModuleFinder.of(Path...) have all the details.

Explicit modules have more to their story. They can be exploded on the 
file system or may be packaged into modular JAR or other formats. What 
is the set of packages in an explicit module? The Module class file 
attribute can help as it contains the set of packages that are exported, 
open or contain service provider implementations. However, it doesn't 
contain the set of packages that not exported, not opened, or don't 
contain service provider implementations. To determine the complete set 
of packages in a module will often require scanning the contents of the 
module. This can mean scanning the file system (exploded module) or 
scanning the contents of a JAR file (modular JAR). This is an area where 
the ModuleFinder API docs could say more. When an exploded or modular 
JAR is scanned, the entries are mapped to candidate package names. If an 
entry maps to a legal package name then it will be added to set of 
packages in the module. If you link this to the encapsulation specified 
by the Class/Module getResourceXXX methods then it starts to become 
clear that non-class resources will be encapsulated if the package isn't 
opened to other modules.

As an optimization (to avoid potentially expensive scanning) the 
module-info can include a ModulePackages class file attribute that 
contains the set of packages in the module. The `jar` tool adds (or 
updates) this attribute when creating (or updating) a modular JAR. This 
means the set of packages in the module may be determined at packaging 
time rather than other phases and the scanning done at packaging time 
needs to exactly match the scanning that would be done when the 
ModulePackages attribute is not present Again, this is an area where the 
ModuleFinder API docs could say more.

-Alan