Hi,
Two modules can have packages with same name if they are not exported
*and* each of the modules loads classes using distinct class loaders, right?
This is a limitation imposed primarily because of ability to load
multiple modules using same class loader. But if the modules that have
types loaded by the same class loader contain concealed (non-exported)
packages of the same name and those packages contain only resources,
then in theory, JPMS could allow such configuration, because for loading
private resources, there's no need to consult the ClassLoader. Each
module could load its private resources with the sole help of its
ModuleReader. Am I right?
Regards, Peter
On 05/10/2017 12:22 AM, Mandy Chung wrote:
On May 9, 2017, at 1:33 PM, Sven Strohschein <nova...@gmx.de> wrote:
There is a very practical example which isn't a bad practice: Resources. Imagine that every Java module has
its own ResourceBundle properties for multi-language support (or imagine any other file which is not a Java
class). These files are typically placed in a "conf", "etc" or "resources"
folder structure and added to the classpath. It should not be necessary that every module has another place
for such resources, that would be a bad solution!
Can you point me to some example library that puts ResourceBundles in these
directories?
The example resource bundles I looked at are typically local and private to a
library/application in its own package. In those cases, the resource bundles
are encapsulated. A module can load a resource bundle from another module if
it’s open to it for access, in the same fashion as resources.
When the localized resource bundles must be distributed in multiple JAR files,
there are several options:
1. leaving those JAR files on classpath will continue to work.
2. loading as automatic modules on modulepath will work if the package has only
.properties file
3. migrate to service provider in modules
Migrating from unnamed module to named module, it requires work to
eliminate the split package [1].
Java throws a LayerInstantiationException on starting the application when
multiple modules have the same resource folder structures... How should
resources be organized in your opinion? Should conf/etc/resources renamed and
restructured to common package names starting with the top level domain?
One option is to move resources to META-INF directory and other directory whose
name is not a valid package name [2].
I don't want to change my projects in such a way for Jigsaw, it shouldn't be
necessary…
Your projects should run fine if you run with -classpath as in JDK 8 unless you
depend on JDK internal APIs. Have you tried that?
Mandy
[1]
http://download.java.net/java/jdk9/docs/api/java/util/ResourceBundle.html#bundleprovider
[2]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000392.html
