Loading an automatic module from an exploded directory

[Alan Bateman]

On 18/04/2020 23:04, Eirik Bjørsnøs wrote:
> :
>
> Could we update ModulePath could to detect "automatic module 
> directories"?. Any directory path name ending with ".jar" could be 
> loaded as an automatic directory module, with the same semantics as if 
> the directory was zipped into a JAR.
>
> This would require a refactoring of deriveModuleDescriptor to allow it 
> being called both from readJar and readExplodedModule. 
> Then readExplodedModule would need an update to detect the lack of 
> module-info.class, and call deriveModuleDescriptor just like readJar 
> does. scan(Path) would need an update to make it skip directory 
> scanning on directories ending with ".jar".
>
> As far as I can tell, this would be (or allow) an implementation of 
> MultiModuleJARs.
>
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.

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.

-Alan