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

Alessio Stalla alessiostalla at
Wed May 10 07:48:18 UTC 2017

Case in point, the rapid application development framework Portofino [1] is
split in several (non-Jigsaw) modules each with its message bundle
fragment, which is named portofino-messages and placed in the empty package.
Also, each module is defined by a class which has to be in a well-defined
package, the same for all modules, but this is more of an implementation
I'm not saying that these are ideal design choices, but that these exist in
the wild.


On 10 May 2017 at 00:22, Mandy Chung <mandy.chung at> wrote:

> On May 9, 2017, at 1:33 PM, Sven Strohschein <novanic at> 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]
> ResourceBundle.html#bundleprovider
> [2]
> 2016-September/000392.html

More information about the jigsaw-dev mailing list