Java Platform Module System

[Alex Buckley]

On 5/1/2017 12:23 PM, Stephan Herrmann wrote:
> 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".

Understood. I need to clarify 6.5.* to accept that multiple packages may 
be visible by the same name. But when we get to accessibility, only one 
of the visible packages should matter.

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

It's hard to respond to the same point in multiple sub-threads. Please 
see my other mail where I accept that package visibility is unrelated to 
'exports'.

Alex