On 01.05.2017 20:47, Alex Buckley wrote:
Yes, the API spec for java.lang.module will be updated to define the
readability relation.
thanks.
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.
I thought we agreed that challenging JLS is the best service we can give to the
community? :)
I prefer not to undermine my scrutiny with too much of an assumed intuitive
understanding.
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:
[...]
I understand the point; when we clarify the API spec for readability, I'll make sure the
JLS usage of "depends" is explicitly aligned.
Thanks, this part resolved.
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.
Asked differently: when it says
"Generally, the rules of the Java programming language are
more interested in dependences than dependencies."
which are the aspects where the rules of the Java programming language *are*
interested in dependencies?
- 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.
You make it sound as if automatic modules are relevant only at runtime.
But how then could requiring an automatic module be resolved at compile time?
Asked differently: how to you plan to ensure that different compilers can
resolve
automatic modules in the same way?
best,
Stephan
