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
