Specifying module paths

[Alan Bateman]

On 15/01/2016 09:06, Robert Scholte wrote:
>
> Suppose there's a logging module and a fat module, which also contains 
> the classes of the logging module, but older.
> In my module-info I have
>     requires logging;
>     requires fat;
>
> These modules are in the same directory. Which class is loaded first 
> and why? If it is the order in the module-info, then I would also like 
> to see an example of the strategy with "requires public".
The module names seems to be unique here so it doesn't matter if these 
two (packaged) modules are in the same directory or different 
directories that you specify to -modulepath in random order.

The issue of modules with different names but overlapping packages is a 
different topic but a topic where there is much to say.

Let's suppose that both module logging and module fat export the same 
package. Now suppose you have a module m1 that requires logging and 
requires fat. In that case you will get a compilation error as m1 is 
reading two modules exporting the same package to m1.  If there is 
subterfuge used to compile this then it will fail at startup/runtime for 
the same reason.

Now suppose that the logging API is exported by module logging but not 
exported by module fat. This may be the example you have in mind. I 
assume the owner of fat has decided to create this uber JAR with an old 
version of logging and without re-packaging it. We'll assume m1 requires 
logging and m1 requires fat as before. In that case, then m1 should 
compile as the logging.* types are only coming from one module.

At run-time then it will fail at startup when logging and fat on the 
application module path. The error is that module logging and module fat 
cannot be defined to the same class loader because they have types in 
the same package. This is not an inherit issue in the module system, 
it's just a implementation limitation with modules on the application 
module path. A more sophisticated launcher would use the Layer API to 
put define modules with overlapping packages to different class loaders. 
It's somewhat tricky for the this to be done automatically when there is 
both an application module path and an application class path. The 
reason is that components on the class path require visibility of 
modules on the application module path. Conversely, automatic modules on 
the application module path need types on the class path to be visible. 
This is something that will need to be sorted out.

I realize this may be more than you were looking for but the point is 
that there isn't any ambiguity as to where the logging classes are 
loaded from. A module is making use of types in package p then those 
types can only come from one module. The use of `requires public doesn't 
change this, instead it just increases the set of modules that are read.

-Alan