Specifying module paths

[Alan Bateman]

On 09/01/2016 17:35, Jonathan Gibbons wrote:
>
> 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.
Definitely worth consideration, it's simple and cute.

I can't think of any bootstrapping issues. Only code in java.can can 
execute in early startup but that's enough for handling UTF-8 and ISO 
8859_1 encoded files (both charsets are specified as standard charsets).

> :
>
> 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.
It will help compile-time and link-time. At run-time then all 
(non-shadowed) modules must be scanned so having the module names just 
makes it faster to ignore shadowed modules.

> :
>
> 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.
Yes, I think so too as otherwise the properties file would need to be 
changed each time that the working directory changes.

>
> 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.
You're right, the API sig doesn't need to change.

-Alan