Thanks a lot for your replies, Mandy and Alan!
> I assume the class path is running on JDK <= 8, right? Otherwise
Is there something missing after "Otherwise"? In fact, I'm looking for a
way to run this
- Java 1.8 on classpath
- Java 9+ on classpath
- Java 9+ on module path
As I've learned by now, ResourceBundleControlProvider implementations on
Java 1.8 will only be loaded via the extension mechanism, which often is
impractical to use. So it seems I'll need to amend my solution described
above to pass in the custom Control explicitly to
ResourceBundle.getBundle(). I could use the ResourceBundleControlProvider
in a MR JAR, but there seems not much of an advantage to doing that.
> For the migration scenario where the resources are in .properties format
then the simplest may be to just deploy the JAR files on the module path
where they will be treated as automatic modules.
In the scenario I have in mind (for educational purposes mainly) the JAR
files contain the properties file as well code and should be usable as
"proper" (i.e. non-automatic) modules as well as on the classpath.
> There are no split package issues unless the resources have been compiled
as .class files.
That's very interesting, it's not what I observe. Having the *.properties
in one and the same package in multiple modules triggers an error upon
start-up:
java.lang.LayerInstantiationException: Package dev.morling.greeter.fr
in both module dev.morling.greeter.german and module
dev.morling.greeter.french
Here's the listing of the incriminating "German" JAR, note how only a
single file is in that "fr" package:
jar -tf german/target/resourceloading-test-german-1.0-SNAPSHOT.jar
META-INF/MANIFEST.MF
META-INF/
dev/
dev/morling/
dev/morling/greeter/
dev/morling/greeter/de/
dev/morling/greeter/de/internal/
dev/morling/greeter/fr/
META-INF/maven/
META-INF/maven/dev.morling.resourceloadingtest/
META-INF/maven/dev.morling.resourceloadingtest/resourceloading-test-german/
dev/morling/greeter/de/internal/GermanGreetingMessagesProvider.class
---> triggers conflict with the "french" module:
dev/morling/greeter/fr/GreetingMessages_de.properties <---
META-INF/maven/dev.morling.resourceloadingtest/resourceloading-test-german/pom.xml
META-INF/maven/dev.morling.resourceloadingtest/resourceloading-test-german/pom.properties
module-info.class
Anything obvious I'm missing here? I could push the complete example to a
repo on GitHub if it helps.
Thanks again,
--Gunnar
Am Fr., 23. Juli 2021 um 08:25 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:
> On 22/07/2021 23:30, Mandy Chung wrote:
> >
> > I assume the class path is running on JDK <= 8, right? Otherwise
> >
> > This is a reasonable approach for the resource bundles to load from
> > both class path and module path when the resource bundles of a given
> > name is packaged in multiple modules/JARs.
> >
> > We considered extending the default ResourceBundle.Control
> > implementation to search with a repackaged bundle name as
> > AbstractResourceBundleProvider::toBundleName in addition to the
> > current default Control::toBundleName. This incurs higher lookup cost
> > (e.g. when it fails with the search of p.foo.Resource_<lang>, it will
> > search p.foo.<lang>.Resource.). What you have is reasonable.
> >
> > Mandy
> I agree. Also just to point out that the ResourceBundle javadoc has a
> "Resource Bundles and Named Modules" section to outline the options for
> deployed resource bundles as modules. For the migration scenario where
> the resources are in .properties format then the simplest may be to just
> deploy the JAR files on the module path where they will be treated as
> automatic modules. There are no split package issues unless the
> resources have been compiled as .class files.
>
> -Alan
>
