This scenario is explicitly discussed in "Jigsaw Under The Hood". The
presentation shows how the definition of readability allows modules to
support "downward decomposition" without affecting the ultimate consumer.
The term "transitive dependencies" needs a little care because sometimes
you'll want it to refer to the transitive closure of all dependencies
(both 'requires' and 'requires public') and sometimes you'll want it to
refer to the transitive closure of only the 'requires public' clauses.
The jlink tool building an image wants the former meaning, while an IDE
inferring the API available by depending on a module wants the latter
meaning.
Alex
On 7/28/2016 8:44 AM, Paul Benedict wrote:
Here is an example use case. Please confirm my understanding. I'd like to
know if transitive dependencies go one module deep or go all the way
through.
1) A@1.0 is published
module A { // exports all packages }
2a) A@1.1 gets split into B@1.0 and C@1.0
2b) A@1.1 uses "requires public" to mimic its previously unsplit self
module A {
requires public static B;
requires public static C;
}
module B { // exports all packages }
module C { // exports all packages }
3a) B@1.1 gets split into X@1.0 and Y@1.0
3c) B@1.1 uses "requires public" to mimic its previously unsplit self
Assuming one level deep...
module A {
requires public static B;
requires public static C;
}
module B {
requires public static X;
requires public static Y;
}
module C { // exports all packages }
module X { // exports all packages }
module Y { // exports all packages }
Will this chain of configuration allow consumers of A to notice no
difference?
Cheers,
Paul
