Java Platform Module System

[Stephan Herrmann]

On 29.04.2017 01:25, Alex Buckley wrote:
> On 4/27/2017 12:38 PM, Stephan Herrmann wrote:
>> Got it. Since now JLS is no longer self-contained it would tremendously
>> help if we could get a list of which parts of the API specification are
>> expected to be considered at compile time. I understand that we need to
>> apply the naming rules for automatic modules. Is there more that should
>> be respected / validated / enforced at compile time?
>
> The JLS was never self-contained as it always referenced a variety of java.lang and java.io types (and more recently
> java.lang.annotation and java.lang.invoke types).

You're right. Still the degree of dependence has changed.

> I have changed 7.3 to state:
>
> "The host system must use the Java Platform Module System (as if by execution of the 'resolve' method of
> java.lang.module.Configuration) to determine which modules are read by M (§7.7.1). It is a compile-time error if the Java Platform
> Module System is unable to determine which modules are read by M."

Thanks, this looks like a good start.

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?


     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?
     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).


 > The JLS, as is traditional, allows a compiler to be as helpful or as terse as it likes w.r.t. the content of the compile-time 
error message.

That's totally fine.


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?

- Another reference links "automatic modules" into JLS and will probably
   link to ModuleFinder.of(Path...), right?


best,
Stephan