On 4/30/2017 3:25 AM, Stephan Herrmann wrote:
For the question at hand, this is what we learn from that improved
reference:
"A readability graph is constructed"
Now we only need a link to the specification that *defines* what is a
readability graph and what is the meaning of "m1 reads m2".
I assume, you want to add a further reference to the "Resolution"
section of the package specification for java.lang.module?
Yes, the API spec for java.lang.module will be updated to define the
readability relation. But instead of waiting for that, I recommend you
watch https://youtu.be/Vxfd3ehdAZc?t=18m15s because readability has been
stable for a long time.
BTW: while pondering if the given package specification is sufficient,
I wonder if "requires transitive" should work through multiple levels:
M1
M2 requires transitive M1
M3 requires transitive M2
M4 requires M3
Does M4 read M1?
It does work through multiple levels, in order to support arbitrary
amounts of refactoring: once you've released a module that someone else
reuses (via 'requires'), then you've committed to your module's name and
API but are free to refactor its content into deeper modules which your
original module "reuses" (via 'requires transitive') for the benefit of
consumers. There is no "re-exporting", just modules being made to read
one another.
So, going top down (because resolution starts from a set of root
modules) :- M4 requires and thus reads M3, and M3 requires transitive
M2, so M4 reads M2. Since M4 reads M2, and M2 requires transitive M1, we
have M4 reads M1.
Looking at 7.7.1:
"The requires keyword may be followed by the modifier transitive.
This causes
any module which depends on the current module to have an
implicitly declared
dependence on the module specified by the requires transitive
directive."
Am I right in assuming that "depends" should cover explicitly and
implicitly
declared dependences? Taking into consideration the subtlety about
dependence
vs. dependency, may I suggest adding s.t. like
"A module M1 is said to depend on another module M2, if it has an
explicitly
or implicitly declared dependence on M2."
(this also makes "depends" a technical term rather than the general
(fuzzy)
English word).
I understand the point; when we clarify the API spec for readability,
I'll make sure the JLS usage of "depends" is explicitly aligned.
Revisiting other references to "Java Platform Module System" inside JLS,
what about the two occurrences in the body of 7.7:
- One reference is used to discriminate "dependence" from "dependency":
From a quick scan, I believe this sentence:
"Generally, the rules of the Java programming language are
more interested in dependences than dependencies."
can probably be made stronger:
"The rules of the Java programming language are not interested in
dependencies, only in dependences.".
Or perhaps the paragraph about dependencies could be removed entirely.
If this interpretation is wrong, another reference to detailed
specification
would be needed. Perhaps it is only JLS, that is agnostic to
dependencies,
whereas the API specification part indeed uses this concept?
This text is an informative note distinguishing the "dependence"
expressed rather statically in the Language, from the "dependency"
module determined rather dynamically by the JPMS. I see no reason to
change it.
- Another reference links "automatic modules" into JLS and will probably
link to ModuleFinder.of(Path...), right?
This text is also an informative note. Automatic modules are discovered
through ModuleFinder.of, sure, and they appear in other places in the
java.lang.module API too -- but none of that is the point of the note.
The point of the note is that the developer doesn't specify 'requires'
any differently for an automatic module than for an explicit module.
Alex
