Portable retrieval of resource bundles across module path and class path

[Alan Bateman]

On 23/07/2021 16:58, Gunnar Morling wrote:
> :
>
>
> Yes, there is such resource which I had created for demo purposes (see 
> the jar -tf  output above):
>
> dev/morling/greeter/fr/GreetingMessages_de.properties
>
> Here's the output you requested:
>
> jar --describe-module --file 
> german/target/resourceloading-test-german-1.0-SNAPSHOT.jar
> dev.morling.greeter.german at 1.0-SNAPSHOT 
> jar:file:///.../resource-loading-test/german/target/resourceloading-test-german-1.0-SNAPSHOT.jar!/module-info.class
> requires dev.morling.greeter.base
> requires java.base mandated
> provides dev.morling.greeter.spi.GreetingMessagesProvider with 
> dev.morling.greeter.de.internal.GermanGreetingMessagesProvider
> contains dev.morling.greeter.de.internal
>
> Interestingly, the dev.morling.greeter.fr 
> <https://urldefense.com/v3/__http://dev.morling.greeter.fr__;!!ACWV5N9M2RV99hQ!ZUKmSO9QXFHdauC6gL-CiFnQwpy43SzKx1ZO-vlnoAi_ugEPld0wxPcWhKC2kMwhqg$> 
> package of the GreetingMessages_de.properties resource file isn't 
> listed there, but it does trigger the split package error later on. 
> Based on what you say, I take it that split package error *is* 
> expected in this situation, it' surprising though to not see the 
> package listed in the output of --describe-module.
>
> If you wanted to reproduce this yourself, the code is here:
>
> https://github.com/gunnarmorling/resource-bundle-test/tree/split-package 
> <https://urldefense.com/v3/__https://github.com/gunnarmorling/resource-bundle-test/tree/split-package__;!!ACWV5N9M2RV99hQ!ZUKmSO9QXFHdauC6gL-CiFnQwpy43SzKx1ZO-vlnoAi_ugEPld0wxPcWhKD4YgQf4A$>
>
> Just run "mvn clean install" on JDK 9+, then "mvn exec:exec -pl 
> :resourceloading-test-runner" for running the application, which 
> should fail.
>
Are you sure this always puts 
dev/morling/greeter/fr/GreetingMessages_de.properties into 
resourceloading-test-german-1.0-SNAPSHOT.jar? I'm quite sure the JAR 
file above doesn't have the fr resource but the JAR file in your 
previous mail seems to include it.

In any case I think this discussion comes down to how the set of 
packages for an explicit module is determined. As explicit modules 
encapsulate their resources by default then it's the set of package 
derived from the non-directory entries that map to legal package names. 
This may be determined at packaging time by the "jar" tool that records 
the set of the packages in the ModulePackages class file attribute, or 
at run-time by scanning the contents of the JAR file. (We need to do a 
better job of specifying that [1]).  So it's different to automatic 
modules where they is no encapsulation and only the .class files are 
used to determine the set of packages.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8230298