Loading an automatic module from an exploded directory

[Eirik Bjørsnøs]

>
> Directories with a ".jar" suffix is clever but I don't think it gets away
> from the substantive issue that Java SE only specifies how automatic
> modules come into being when they are packaged as JAR files. I could also
> imagine tools and libraries that scan tripping up on directories named
> ".jar". There are also many libraries that peek into the JAR manifest with
> the java.util.jar APIs so they will be surprised too.
>

I'm sure we could agree on some other convention to stop consumers from
tripping on ".jar" in a directory name. (They should check
ZipEntry.isDirectory, anyways)

Just on MultiModuleJARs (and its buddy #MultiModuleExecutableJARs). This
> would probably be significant enough to need a JEP. It would need to
> explore whether the modules in the JAR are observable when the JAR file is
> on the module path, this amounts to deciding if they are resolved and
> loaded into the boot layer or child later. If observable on the module
> path then it mean javac would need to support it. Automatic modules would
> bring many discussion points to the table. One of their important roles of
> automatic modules is to bridge to the class path so what does not mean when
> everything is packaged into the same JAR file, does the JAR file have a
> directory with the "class path" too? There are implications for jlink and
> several other tools (jar) aswell. So in summary, and at least in my view,
> there is a lot more exploration needed before doing just implementation
> changes to support "exploded automatic modules" in JAR files.
>

Ok, so #MultiModuleJARs obviously has a much broader scope than what I
originally thought. I'm not suggesting that the semantics of this JAR file
I produce should change. The JDK should remain blissfully unaware that I
packed modules somewhere deep into /META-INF/. I don't expect javac, jlink,
the java command line (or java -jar) to find these modules, nor know about
their existence. Loading these bundled modules would require rolling your
own custom main method using ModuleLayer and friends to set this up. I'm
not suggesting we standardize how this loading should happen.

All (I think) I'm suggesting is a local fix in ModulePath to allow reading
automatic modules from ZIP filesystem paths given that some specified
convention signals that this path represents an unpacked dusty jar. This
convention would need to be documented (in ModulePath?), but that should
represent a small javadoc change. The semantics of what an automatic module
is would not change.

ModulePath already supports reading proper modules from such ZIP paths, so
one can claim that not supporting automatic modules represents a bit of an
asymmetry.

I think this change unlocks potentially useful new distribution models for
modules, and if #MultiModuleJARs was to be revisited, something like this
would probably be required as a building block anyway.

Cheers,
Eirik.