Specifying module paths

[Jonathan Gibbons]

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