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
