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:
>> 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.
>
> [...]
> (C)-style property is now expressed in 4.3.4:
>
> "Two reference types are the same compile-time type if they are declared in compilation units associated with the same module
> (§7.3), and they have the same binary name (§13.1), and their type arguments, if any, are the same, applying this definition
> recursively."

Admitted, this part looks good. And so does 6.5.5.2.

Meanwhile I've come to the interpretation that the main weakness of JLS concerns
handling of same-named packages in different modules.

Trouble seems to start at a difference between 6.5.5.2 and 6.5.3.1/2:
To identify a type, that type must be accessible from the current module,
but for identifying a package, the package only needs to be visible.
Ergo: identifying a package does not consider exports.

Furthermore, 6.5.3.2 implies that each qualified name uniquely defines a package,
when it speaks of "the member named Id within the package named by Q". Note the
two occurrences of "the".

This finally undermines the definition of accessibility (6.6.1), when it speaks
of the "module to which the package is exported". I read this as follows:
When M1 exports p1 to M2, this makes all public members of p1 accessible in M2,
even those that belong to totally unrelated modules, which may not export p1.

I recall Alex answering "this is still being clarified / discussed" to several
questions in this area.

As a result I can only conclude: JLS still doesn't tell us which module system
to implement.


If this were just a minor omission, why then would it still be subject to
discussion, this late in the game? I see one possible explanation: changing the
spec may involve much more trouble than meets the eye. Changes concerning packages
are very much focusing on the hierarchical structure of packages and sub packages,
despite the fact that 7.1. has always been describing this structure as having
    "no significance in itself".
7.4.3 already jumps through hoops, trying to balance the hierarchy-based notion of
"technically observable" with the concept of "really observable" which disregards
the hierarchy.
In my view, a forest rooted at toplevel packages is not suitable for specifying
the rules of accessibility, where each module may have a different interpretation
of a given package name, in a way that is completely unrelated to hierarchy.
Since "exports" refers to a package, this notion must be better aligned with modules.

best,
Stephan