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
