Why is requires transitive limited to the modules that directly require the module containing it?

Question

Let say there is module x that exports something. Then there is module a:

module a {
 exports some.package.from.a
 requires transitive x;
}

Then there are 100 modules b that require a :

module b1 {
  exports some.package.from.b1
  requires a;
}
...
module b100 {
  exports some.package.from.b100
  requires a;
}

Then there are 100 modules c that require respective bs

module c1 {
  requires b1;
}

...
module c100 {
  requires b100;
}

Assume c1 ... c100 do not need to know about packages from a. Those are only used by b1 ... b100 internally and thus not transitively required.

However the API exported by b1 ... b100 uses classes in packages exported by x.

Modules c1 ... c100 can NOT see those. Trying to compile them, results in

Compilation failure:
(package x.y.z is declared in module x, but module c1 does not read it)

Why is requires transitive limited to the modules that directly require the module containing it? How can the issue described above be solved without editing 100 module-info files?

---

UPDATE: There are at least 3 ways to "fix" this:

• add requires transitive a to b1 ... b100
• add requires transitive x to b1 ... b100
• add requires x to c1 ... c100

While all would work in this particular case, it is not clear which one should be used and what the side effects of each of them are. Moreover this is only 3 level deep hierarchy - with more levels, it gets even more complex.

If requires transitive was to be transitive for all dependents (as the word transitive implies) this would be solved automatically. If there was no transitive there would have been only one way to approach the issue. With transitive limited to the direct dependents there are "options" which needs to considered, but it seams not enough information is provided for one to make proper choice.

Answer 1

If a module (your b's) use another module's (your x) types independently of an interspersed requires transitive (b's on a's), they should require them directly and not rely on implied readability.

In your case, b's should absolutely requires transitive x.

Answer 2

Ok, 4 years later but I'll have a crack at some of those questions.

I know one can figure out that it's x but that's not obvious in complex dependency graphs.

I think the key here is that to a large extent we only ever need to look 1 level deep in a dependency graph. That still might be quite a lot to look at but I believe we would not look to solve this outside of the C's or B's.

That is, we have the compilation error with the C's. Either we add the requires X to C's OR change the B's somehow (with 2 options to look at).

That is, we are relatively unlikely to modify any module deeper in the dependency graph because other modules have somewhat proven they don't need X. Modifying modules that currently don't need to "transitively export" X would not seem correct. [Edit: given we generally desire to minimise what is transitively exported]

Therefore, our solution should be found at a max depth of 1 in the dependency graph - In the C's or B's.

StuartMarks I am still not 100% convinced because you assume b knows that types come from x while from b's perspective they come transitively from a.

I think it's more that B's public API explicitly does not include X. B's use of X was deemed for internal purposes only (perhaps incorrectly).

It's when we are compiling C that we see that does not match up with B's module-info / what B makes readable. It's at this point we have an issue with B's exported API (what B makes readable) and we have the options:

• Q1: Was B API supposed to export A (and X via transitive) ?
• Q2: Was B API supposed to export X only (and not include A) ?
• Q3: Was B API correct and we need all the C's to require X ?

If the answer was Q1 - Yes, then we change B's to requires transitive a;

If the answer was Q2 - Yes, then we change B's by adding requires transitive x;

If the answer was Q3 - Yes, then we change C's by adding requires x;