Specifying module paths

[Alan Bateman]

On 07/01/2016 23:39, Jonathan Gibbons wrote:
> :
>
> 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).

Allowing an entry to be text file is nice but I wonder if a file of just 
locations could work too.

With the existing module path then javac or the runtime needs to look at 
all modules in a directory to get their name and check for duplicates. 
It could do the same with a file of just locations. One benefit is that 
it avoids the error case where a name maps to a location of a module 
that has a different name.

One other thing to mention is service binding as this involves finding 
all modules that provide implementations of a service type. A name -> 
location doesn't help with that as it essentially amounts of finding all 
modules. I can see name -> location helping the compiler of course as it 
won't need to examine all modules.

Assuming this moves forward then there are details to work out: The file 
encoding is one that isn't as obvious as it might seem because the 
locations/property values are file paths. For relative file paths then 
they could be relative to the properties file or relative to the working 
directory. One other thing is the ModuleFinder API, the of(Path[]) 
method might have to change to of(String[]) or an overload introduced.

-Alan