Problems with non-exported split packages (for resources/files)

[Peter Levart]

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