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