Winding up this discussion ...
While the use of a properties file to provide a mapping from module name
to file system artifact has some attractive properties, it seems that
there is insufficient interest to pursue it further at this time. We can
always revisit it later. The same applies to variant suggestions, such
as a plain text file containing a list of module artifacts.
Instead, there is clearly interest in putting compiled module artifacts
directly on the module path.
To that end, we will modify the specification of a module path such that
the appearance of a file (as compared to a directory) on a module path
will be treated as though it was in a directory containing just that
file. A directory on the module path will continue to be treated as now.
The corollary is that "exploded modules" (represented by a directory
hierarchy) cannot themselves be placed directly on the module path; they
must continue to be placed in a directory on the module path.
This will apply to all JDK tools that support options whose value is a
module path.
-- Jon
On 01/07/2016 03:39 PM, Jonathan Gibbons wrote:
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
