Much clearer, still a few comments.
On 27.08.19 09:05, Alan Bateman wrote:
- 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.
For the original issue in this thread this could actually be a solution: hide
non-java packages from the layer implementation. Since those files aren't even
meant to be accessed at runtime I don't expect any harm. Except that we'd be
relying on details of the default implementation.
- 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.
That's where I was looking and that's why I wondered if those packages are
doomed to be always "encapsulated".
At run-time, a non-class resource will be encapsulated if the corresponding
package is not open to other modules.
As you seem to see both open and not-open as possibilities, I guess as a last
resort there's API where the package can still be opened at runtime, despite JLS
7.7.2. Fair enough.
> In your "about_files" case then I assume the two JAR files would have worked
> as automatic modules.
yes, they did. Only "improving" them to explicit modules broke clients.
Stepping back, I see one source of confusion in the 3-valued semantics of the
term "encapsulated":
(a) a package can be encapsulated, so JPMS rules prohibit any access from
outside the module
(b) a package can be exported / visible, so JPMS includes it in uniquely-visible
checks.
(c) a folder can be legacy / not-a-package, so JPMS rules don't apply at all.
When packaging files that are irrelevant for access by clients, one might be
tempted to use (a) but when run in a single-classloader runtime this can
unexpectedly blow up. Here, encapsulation does not establish the desired
independence, as common sense suggests.
For the problem at hand I see two possible solutions:
- the "hack" of forging the ModulePackages attribute
- rename the folder to change it from encapsulated (a) to legacy (c).
Both options have some kind of negative smell, so let me ask: which solution is
recommended when trying to group legalese files in a folder inside a jar that
should NEVER be subjected to JPMS-specific conflict checks?
Option 3 (?):
- never run applications in single-classloader runtimes
thanks,
Stephan
PS: Bottom line for tool implementors seems to be: none of these problems should
be reported at build time, just let it crash at runtime?
