Specifying module paths

[Jonathan Gibbons]

This is a follow-up to some of the recent email discussions regarding 
the use of the module path.

The "State of the Module System" [1] defines a _module path_ as follows:

> A module path is a sequence of directories containing module artifacts 
> which are searched, in order, for the first artifact that defines a 
> suitable module.

However, build systems may find it inconvenient to aggregate the 
necessary set of modules for an application into such a sequence of 
directories. For example, see [2].  In general, it is undesirable to 
have to copy jar files into directories on the module path, partly 
because of the IO cost involved, and partly because of the number of 
duplicated files that might ensue.

One possibility is to allow the module path to directly contain entries 
specifying modules, as compared to directories containing modules. See 
JDK-8144665 [3]. While feasible, that would put us back in the world of 
long paths, and hence long command lines, which are problematic on some 
platforms, and which have led to ad-hoc workarounds such as the use of 
so-called @-files, to workaround around any platform-specific command 
line limitations.

Another possibility would be to use symbolic links, so that the 
directories on the module path do not directly contain the necessary jar 
files but instead contain links to those jar files. But symbolic links 
are not uniformly supported on all systems, which would make such an 
approach somewhat problematic.

This note suggests a similar-but-different approach.

The proposal is that it should be possible to represent an entry on the 
module path as a text file in Java properties file format, such that it 
provides a mapping from a module name to a location on the host system 
where the contents of the module can be found. The representation of the 
module itself could be any form that could otherwise appear in a 
directory on the module path, such as a modular jar or exploded module. 
Just as a file system directory provides a mapping from a name to the 
content of a module, so too could such a properties file, which could be 
created at minimal cost, without copying any files, and which would work 
uniformly across all platforms.  Although there need not be any inherent 
restrictions on the use of such entries on the module path, in the 
extreme case, the location of all the application modules for an 
application could be specified in a single properties file entry on the 
application module path.

While conceptually similar to the use of @-files, the use of property 
files to express a large number of entries on a module path would 
provide a more structured solution that would be uniformly adopted 
across all tools that process module paths, including but not limited to 
the Java launcher (java), linker (jlink), and compiler (javac).

-- Jon


[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005582.html
[3] https://bugs.openjdk.java.net/browse/JDK-8144665