On 01/09/2016 08:16 AM, Alan Bateman wrote:
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
I think there are enough advantages to using a properties file that it
is worth consideration, unless there are serious technical reasons (such
as difficulty using java.util.Properties::load while bootstrapping the
system) to avoid them.
One of the implications of specifying a properties file format was that
java.util.Properties specifies an encoding of ISO 8859-1, and how to
escape characters within that. However, there is also JEP 226,
investigating UTF-8 property files. The point here is that we can
leverage existing well known standards for specifying this file.
It is not clear to me there is any significant benefit from avoiding the
error case where a name maps to a module of a different name. Yes, that
should be checked if and when the full module declaration is accessed,
but the error is not materially different from any of the other errors
that can occur when reading a module declaration. And there are
significant benefits from specifying that the name must be available in
the properties file, because it will help to avoid opening and reading
the module definition unnecessarily.
The name->location mapping helps _all_ consumers of the module path,
including service binding, because it can be used to avoid opening
modules that have been shadowed by entries appearing earlier on the path.
The question about relative paths in the file is more interesting. I
would expect that most uses of this feature would use absolute paths. If
a relative path was used, then a path relative to the directory
containing the properties file would make the most sense.
Finally, I don't see the need to change the signature of
ModuleFinder.of(Path...) method, other that to change the name of the
parameter from "dirs" to "paths", such that one of the entries in the
array could be the path for a properties file, just as it might be the
path for a modular jar file as discussed in alternative proposals. In
other words, I would assume that ModuleFinder.of would provide direct
support for reading properties files as well as directories, as a means
of locating module definitions.
-- Jon
