Specifying module paths

[Paul Benedict]

What will the interaction be between a .properties and patching? It would
make sense, I think, to allow a project to specify all the modules for
compiling source, but then allow overrides for compiling/executing tests.
If overrides aren't available, then overrides will have to be calculated
manually to generate another .properties file. This isn't a complaint; it's
just speaking the conclusion aloud for input.

Another option would be for .properties to be in a hierarchical format --
which I believe already exists, if I am not mistaken.

Cheers,
Paul

On Sat, Jan 9, 2016 at 11:35 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> 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
>