Java Platform Module System

[Stephan Herrmann]

On 25.04.2017 19:02, Alex Buckley wrote:
> On 4/25/2017 1:20 AM, Stephan Herrmann wrote:
>> On 25.04.2017 03:50, Alex Buckley wrote:
>>> Dependency resolution in JPMS is accomplished by the static 'resolve'
>>> method of java.lang.module.Configuration.
>>
>> Interesting.
>> Are you saying the semantics of JPMS depends on the implementation
>> of one or more methods in java.lang.module.Configuration and friends?
>> Are all mentions of JPMS inside JLS intended as references into JDK API?
>> How are compiler engineers expected to use this information?
>
> JPMS semantics (notably, dependency resolution) are defined by the API specification (not the implementation) of
> java.lang.module.Configuration and friends. JLS references to JPMS are references to this Java SE API.
>
> Alex

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?



Let me add a friendly reminder, that we are still waiting for a
specification that unambiguously tells us which module system to implement.
For illustration:

(A) Is JPMS a module system that keeps the semantics of qualified names as
they are in Java 8 and only superimposes encapsulation boundaries?
(i.e., each type is globally uniquely identified by its qualified name).

(B) Is JPMS a module system that maintains the assumption that from the
perspective of each module all relevant types can be distinguished using
their qualified name?
(i.e. admitting identical qualified names as long as no compilation of one
module will ever encounter several candidates at once).

(C) Is JPMS a module system that establishes a separate namespace for each
module, where types with identical qualified name - but defined in different
modules - need to be distinguished?
(i.e., uniqueness is primarily required for module-prefixed qualified names).


Despite some efforts I fail to find a definite answer in JLS (and Alex
mentioned that some of this is still being discussed). Still JLS as of today
sounds mostly like (A). To me (B) sounds like the natural choice, but I
understood Alex as saying it *should* be (C). I don't see, however, how the
conceptual framework of JLS could possibly support such design.


Stephan

PS: I'm also having hard times to imagine, how those parts of the
specification, that are focused on compilation units, can possibly define
aspects like accessibility when looking at .class files, not compilation
units - but hopefully, this is just a technicality in how the spec is worded,
not a conceptual problem.