Portable retrieval of resource bundles across module path and class path
Gunnar Morling
gunnar at hibernate.org
Fri Jul 23 17:23:00 UTC 2021
> 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 git at 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.Bateman at 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 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
>
>
>
More information about the jigsaw-dev
mailing list