package hierarchy?

[Alex Buckley]

The quote from 6.5.3.2 is incorrect -- the paragraph beginning "If Q 
does not name ..." is deleted. We discussed this in May, where I 
explained why the section is the way it is. See 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012779.html.

I have also explained that the meaning of the qualified package name 
Q.Id is NOT specified in terms of the simple package name Q. See 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012488.html. 
That's why there is no requirement in 6.5.3.2 that Q be uniquely 
visible, only Q.Id.

Stepping back, you seem to have a concern that the spec no longer relies 
on hierarchy to give meaning to packages yet continues to present 
subpackages as a feature of the language; and you believe this is a 
tension that will have deleterious effects on ordinary developers. I do 
not believe it will, because ordinary developers have always understood 
that a package-access type in package p1.p2 is NOT accessible from the 
"related, but not really" package p1.p2.p3. In the modular world, I do 
not believe that a developer who exports p1.p2 has any expectation that 
p1.p2.p3 is exported too. We deliberately designed the syntax of exports 
-- one package per 'exports', no wildcards, no duplicates -- to ensure 
explicit, methodical enumeration of the packages which represent the 
module's contract with the outside world.

Alex

On 7/17/2017 3:59 AM, Stephan Herrmann wrote:
> This continues a discussion we had in January, but still isn't
> fully resolved in JLS 2017-06-26:
>
> Does the parent-sub relation of packages bear any meaning
> from the JLS p.o.v.?
>
> On 2017-01-10 Alex conceded:
>    "... you can consider all packages as unrelated to each other."
>
> Still JLS 6.5.3.2 has this (my emphasis):
>
> "If a package name is of the form Q.Id, then Q must also be a package name.
>   The package name Q.Id names a package that is the member named Id
>   *within the package named by Q*.
>   If Q does not name an observable package (§7.4.3), or Id is not the
> simple name
>   of an observable subpackage of that package, then a compile-time error
> occurs.
>
>   If Q.Id does not name a package that is uniquely visible to the current
>   module (§7.4.3), then a compile-time error occurs."
>
> Now, what's the meaning of "the package named by Q"?
>
> Technically, we need to consider Q as a package name, whose meaning
> is determined by 6.5.3.1 or 6.5.3.2.
> This inevitably implies that Q must be uniquely visible.
>
> In the end, this requires, e.g., that package "java" be uniquely visible in
> every Java 9 program. Or: every Java 9 program (even JDK itself) is
> illegal.
>
>
>
> I *imagine*, the spec authors intended two different definitions of
> PackageName: an internal definition that is applied whenever JLS
> itself refers to a package name, and an external, applicable to
> type or package references in the source code.
> I imagine, only the external definition has to apply the second
> paragraph requiring unique visibility, whereas internal references
> to PackageName should be unaffected by this addition.
>
> *Perhaps*, the phrase "If Q does not name an observable package"
> intends to override the normal interpretation of package names, to
> require only observability, not unique visibility, but this doesn't
> work if first name resolution is obliged to check unique visibility
> and possibly fail compilation.
>
> Now correcting JLS in its current form will be quite tedious, like:
> "within a package that is identified by the name Q, by applying
> 6.5.3 recursively while ignoring any requirement of unique visibility".
> Yikes.
>
> am I missing anything?
> Stephan
>
> Ceterum censeo ...
> I'm really looking forward to the day, when JLS is refactored to
> specify the language with no parent-sub package relation whatsoever,
> leaving it entirely to any host system, to use prefixes of package
> names for grouping stuff in containers like folders of a file system.
> Wouldn't that make for a much cleaner specification?
>
> OTOH, wherever JLS and compiler messages surface the concept of
> a package "hierarchy", it will influence user expectations: Having
> learned about package hierarchies users may likely expect that
> exporting package "p1.p2" will also make "p1.p2.p3" accessible
> just like "p1.p2.MyClass".