Non-java resources creating split-package problems?

[Stephan Herrmann]

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?