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
