Loading an automatic module from an exploded directory

Eirik Bjørsnøs eirbjo at gmail.com
Thu Apr 9 15:42:24 UTC 2020


The current implementation of automatic modules seems to assume that an
automatic module is always packaged as a jar file.

I'm working on a module runtime where this is not always the case, and the
limitation has become a bit of a challenge.

I want to package applications (modules + runtime) at build time into a
single jar for distribution.

The runtime loads modules from directories within its own jar.  This means
that ModuleFinder.of(Path..) receives module locations in the form:

jar:file:///path/to/single.jar!/META-INF/modules/module-1.0/

This works fine as long as modules are explicit. (With the unrelated
limitation that the multi-release feature also seem to assume jar files)

Loading automatic modules this way is not as easy.

First, it requires duplicating non-trivial amounts of private, slightly
intricate code from ModulePath.deriveModuleDescriptor and friends.

Second, since deriveModuleDescriptor assumes jars on disk, it uses JarFile
scanning to find all packages to add to the automatic module. So the
scanning code must be rewritten to scan for class files (and
META-INF/services/ files) within the sub-directory in the main jar instead.

I have also identify an additional use case which is to allow hot-deploying
automatic modules during development from target/classes using a Maven
plugin.

These use cases are probably on the fringes of what the module system was
designed to support, but it did made me wonder if some small changes maybe
could make this easier.

Availability of some public API to create ModuleFinder for an automatic
module loaded in non-standard ways would be helpful.

The 'non-standardness' I have been able to identity in my case is:

1: The fallback name for the automatic module. In my case, there's no jar
file name to investigate, so instead I use the Maven artifactId directly
(after cleaning it)

2: The set of paths to use as input for identifying packages in the module
and the set of service files to use as input for defining 'provides'
attributes.

Here's a strawman API which I think would support my use case :

ModuleFinder auto = ModuleFinder.automatic(Path location, String
defaultName, Set<String> packages, Set<String> serviceNames)

Any feedback, ideas or similar experiences would be appreciated.

Cheers,
Eirik.


More information about the jigsaw-dev mailing list