> 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.
Yes, I'm quite sure, unless I'm doing something really stupid :) Here's the steps for reproducing: git clone g...@github.com:gunnarmorling/resource-bundle-test.git git checkout split-package cd resource-bundle-test mvn clean install jar -tf german/target/resourceloading-test-german-1.0-SNAPSHOT.jar jar --describe-module --file german/target/resourceloading-test-german-1.0-SNAPSHOT.jar jar -tf shows the resource dev/morling/greeter/fr/GreetingMessages_de.properties, but jar --describe-module doesn't show the dev.morling.greeter.fr package. > I think this discussion comes down to how the set of packages for an explicit module is determined. Agreed, and I think I got my answers. I'll try and do a quick blog post about this topic, I haven't seen much discussion of ResourceBundleProvider for instance. Thanks a lot, --Gunnar Am Fr., 23. Juli 2021 um 18:54 Uhr schrieb Alan Bateman < alan.bate...@oracle.com>: > 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 > > >
