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
