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.gibb...@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 >
