Re: Portable retrieval of resource bundles across module path and class path

[Christian Stein]

Hi Gunnar,

I skimmed your post briefly and will read it in detail later -- though I
wonder
whether my over 4 years old SO question is answered as a side-effect by
your findings.

https://stackoverflow.com/questions/44167502/how-to-configure-resourcebundle-no-fallback-control-in-java-9

Cheers,
Christian

On Tue, Aug 31, 2021 at 10:25 AM Gunnar Morling 
wrote:

> Hi all,
>
> I've written a quick blog post about my experiences with
> ResourceBundleProvider et al.:
>
>
>
> https://www.morling.dev/blog/resource-bundle-lookups-in-modular-java-applications/
>
>  The scenario I'm describing is that of a "well-structured monolith", with
> each module contributing its own resource bundle(s). It took a while to set
> things up in a way working with Java 9+ (with module and with classpath)
> and Java 8, but I've found my ways in the end.
>
> Thanks again for all the feedback and input you provided!
>
> Best,
>
> --Gunnar
>
>
>
> Am Fr., 23. Juli 2021 um 21:14 Uhr schrieb Mandy Chung <
> mandy.ch...@oracle.com>:
>
> >
> >
> > On 7/23/21 4:17 AM, Gunnar Morling wrote:
> >
> > 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"?
> >
> >
> > It was a typo (I should have taken it out).
> >
> > 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.
> >
> >
> > Right, this is indeed the simplest approach if the JAR file contain
> > resource bundles in .properties format and no .class files in that
> > package.  i.e. you can keep the resource bundles in `dev/morling/greeter`
> > and deploy them 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.
> >
> >
> > It's common to have the resources packaged in separate JARs from the code
> > and also an application includes all resources.   This educational
> purpose
> > demo shows an advanced feature.
> >
> >
> > > 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
> > <
> https://urldefense.com/v3/__http://dev.morling.greeter.fr__;!!ACWV5N9M2RV99hQ!fILkGEkNjEpD7sQnRSKHS3M4qZY3lXvfXij2Q4XgaGa9P1mVdmrAFrdcvVKsPREq3A$
> >
> > in both module dev.morling.greeter.german and module
> > dev.morling.greeter.french
> >
> >
> > this looks a little suspicious.   GreetingMessages_de.properties should
> be
> > expected in dev.morling.greeter.
> >
> > Mandy
> >
>

Re: Portable retrieval of resource bundles across module path and class path

[Gunnar Morling]

Hi all,

I've written a quick blog post about my experiences with
ResourceBundleProvider et al.:


https://www.morling.dev/blog/resource-bundle-lookups-in-modular-java-applications/

 The scenario I'm describing is that of a "well-structured monolith", with
each module contributing its own resource bundle(s). It took a while to set
things up in a way working with Java 9+ (with module and with classpath)
and Java 8, but I've found my ways in the end.

Thanks again for all the feedback and input you provided!

Best,

--Gunnar



Am Fr., 23. Juli 2021 um 21:14 Uhr schrieb Mandy Chung <
mandy.ch...@oracle.com>:

>
>
> On 7/23/21 4:17 AM, Gunnar Morling wrote:
>
> 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"?
>
>
> It was a typo (I should have taken it out).
>
> 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.
>
>
> Right, this is indeed the simplest approach if the JAR file contain
> resource bundles in .properties format and no .class files in that
> package.  i.e. you can keep the resource bundles in `dev/morling/greeter`
> and deploy them 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.
>
>
> It's common to have the resources packaged in separate JARs from the code
> and also an application includes all resources.   This educational purpose
> demo shows an advanced feature.
>
>
> > 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
>
>
> this looks a little suspicious.   GreetingMessages_de.properties should be
> expected in dev.morling.greeter.
>
> Mandy
>

Re: Portable retrieval of resource bundles across module path and class path

[Mandy Chung]

On 7/23/21 4:17 AM, Gunnar Morling wrote:

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"?


It was a typo (I should have taken it out).


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.




Right, this is indeed the simplest approach if the JAR file contain 
resource bundles in .properties format and no .class files in that 
package.  i.e. you can keep the resource bundles in 
`dev/morling/greeter` and deploy them 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.


It's common to have the resources packaged in separate JARs from the 
code and also an application includes all resources.   This educational 
purpose demo shows an advanced feature.




> 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


this looks a little suspicious.   GreetingMessages_de.properties should 
be expected in dev.morling.greeter.


Mandy

Re: Portable retrieval of resource bundles across module path and class path

[Alan Bateman]

On 23/07/2021 18:23, Gunnar Morling wrote:

:

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 wasn't able to duplicate this and don't immediately see how how this 
project ends up with GreetingMessages_de.properties in 
dev/morling/greeter/fr.




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


ResourceBundleProvider is an advanced feature and most projects will 
likely get by by including the resources with the application. It's only 
when you separate them and wish to deploy the translations as modules 
that you need to know about this feature.


-Alan

Re: Portable retrieval of resource bundles across module path and class path

[Gunnar Morling]

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

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



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

Re: Portable retrieval of resource bundles across module path and class path

[Gunnar Morling]

Am Fr., 23. Juli 2021 um 15:05 Uhr schrieb Alan Bateman <
alan.bate...@oracle.com>:

> On 23/07/2021 12:17, Gunnar Morling wrote:
> > :
> >
> > > 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:
>
> I should have been clearer that the "no split package issues" comment
> was in the context of automatic modules where you "move" an existing JAR
> file containing .properties files from the class path to the module
> path. The .class files in the JAR file are used to determine the set of
> packages in the automatic module so if there are no .class files then it
> doesn't have any packages.
>
> That said, I'm surprised by the exception message as suggests there must
> be dev.morling.greeter.fr classes or resources  in the
> dev.morling.greeter.german module. I think I'd need to see the output of
> `jar --file= --describe-module` to be sure.
>

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

Just run "mvn clean install" on JDK 9+, then "mvn exec:exec -pl
:resourceloading-test-runner" for running the application, which should
fail.

Thanks,

--Gunnar


> -Alan
>

Re: Portable retrieval of resource bundles across module path and class path

[Alan Bateman]

On 23/07/2021 12:17, Gunnar Morling wrote:

:

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


I should have been clearer that the "no split package issues" comment 
was in the context of automatic modules where you "move" an existing JAR 
file containing .properties files from the class path to the module 
path. The .class files in the JAR file are used to determine the set of 
packages in the automatic module so if there are no .class files then it 
doesn't have any packages.


That said, I'm surprised by the exception message as suggests there must 
be dev.morling.greeter.fr classes or resources  in the 
dev.morling.greeter.german module. I think I'd need to see the output of 
`jar --file= --describe-module` to be sure.


-Alan

Re: Portable retrieval of resource bundles across module path and class path

[Gunnar Morling]

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_, it will
> > search p.foo..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
>

Re: Portable retrieval of resource bundles across module path and class path

[Alan Bateman]

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_, it will 
search p.foo..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

Re: Portable retrieval of resource bundles across module path and class path

[Mandy Chung]

On 7/22/21 12:23 PM, Gunnar Morling wrote:

Hi all,

I'm trying to figure out how a modular application should handle
cross-module resource bundle look-ups, supporting running on both the
module path and the class path. At a first look, resource bundle semantics
in the two modes are at odds with each other:

* When running on the classpath, all modules (or JARs, I should say) would
have to provide their bundles in one and the same package, so
ResourceBundle.getBundle() will pick them  all up
* When running on the module path, this would lead to split package issues,
so each module has to use a distinct package and a ResourceBundleProvider
which exposes the module's bundles

So what I ended up doing is using the distinct package approach with RBP to
make things work when running on the module path. When running on the class
path, I'm using a ResourceBundleControlProvider whose returned Control
adjusts bundle names to match the package naming pattern used in the
different modules.

Is this the recommended approach for solving the issue of making resource
bundles in a modular application functional on module and class path? Or is
there a simpler approach to achieve the same?


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_, it will search 
p.foo..Resource.).  What you have is reasonable.


Mandy