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@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
