On 11/01/2024 21:57, PavelTurk wrote:
:
a) we see that gson reads 5 modules. At the same time gson requires
only 1 module:
module com.google.gson {
exports com.google.gson;
exports com.google.gson.annotations;
exports com.google.gson.reflect;
exports com.google.gson.stream;
requires transitive java.sql;
}
Do I understand it correctly that extra 4 modules are read via java.sql?
In the API docs for java.sql you will see that it requires transitive
java.logging, java.transaction.xa, and transitive java.xml. This means
that com.google.gson will read java.sql, java.logging,
java.transaction.xa, and transitive java.xml. In addition, every module
reads java.base so that explains the edges you see in the readability graph.
3. Do I understand it correctly if some explicit module (with
module-info) from webserver layer will require any automatic module
from webserver layer then this explicit
module will read ALL automatic modules from both layers?
If an automatic module is enumerated during resolution when all
observable automatic modules are enumerated. If an explicit module
requires an automatic module then the explicit module will read all
enumerated automatic modules.
That said, there is an open issue around readability when there is a
stack or tree of configurations when there are modules with the same
name in different configurations. The science is right when they are all
explicit modules but there is an issue when there are automatic modules
in configurations other than the configuration for the boot layer and
where the module names aren't globally unique. This is the issue we
were discussing in other thread where it will require both specification
and implementation changes to address.
-Alan
