Compiling Java 9 (take 2)

[Alex Buckley]

On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
> On 01/07/2017 01:37 AM, Alex Buckley wrote:
>> On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
>>> Given that types are identified by qualified names that
>>> do not contain the module name, this distinction doesn't seem to be
>>> possible per JLS.
>>
>> Per 7.3, javac is associating a first other.Other type with module
>> Base, and a second other.Other type with module Test. The first
>> and second types have no relationship to each other, so there are no
>> conversions between them, so Base's test(other.Other) method is
>> not applicable to the invocation b.test(other).
>>
>> It's true that 7.3 also says that all the compilation units of Base
>> are visible to Other, since Other reads Base. javac is
>> effectively hiding Base's other.Other type from code in Other, since
>> Other already has an other.Other type. It's possible we need to
>> specify this explicitly.
>
> Is some similar magic applied to packages, too?
> I.e., can different modules contain *different* packages by the same name?
> Or is that situation always considered a split package?

Different modules can contain different packages of the same name.

> More practically, if several modules M0, M1 ... have some compilation units
> which all declare package P, what's the effect if
>    M0 exports P
> ?

It depends on whether anyone reads M0. If no-one reads M0 then M0's 
packages (whether exported or concealed) are irrelevant to the 
compilation of other modules.

> Assume a type M1/P.T1, under which conditions (if at all) is this type
> covered by the given export?
> - if M0 requires M1 (which results in all compilation units of M1 being
> visible in M0)?
> - if M0 requires M1 and M1 exports P?
> ...
>
> Which section(s) in JLS defines these issues?

This is a question about whether M0's visibility of packages and 
compilation units should include M1's P package/compilation units or 
not. Currently 7.4.3 says "yes", because that gives the JLS the 
vocabulary to reason about (i.e. mandate errors for) illegitimate module 
graphs, where M0 has visibility to its own P plus the P of M1 which M0 
reads (and this is an illegal module graph for the boot layer regardless 
of whether M1 exports P). This reasoning we want is still being clarified.

> Asked differently: is "exports P" to be taken literally as exporting
> a tangible entity of kind package, or is "exports P" a shorthand for
> making all types accessible which are declared in compilation units that
> ...
>   - declare P
>   - are observable / visible / accessible at the location of the export
> ?

I understand the question, and that its answer may affect the role of 
package symbols in your compiler. As I said, still being clarified.

> Can a module export a package even if no compilation units of that package
> are associated with the current module? The export might only affect types
> exported from some other required module. Is that allowed?

There is no re-exporting of another module's packages. Per lang-vm.html, 
"It is a compile-time error if the package specified by exports is not 
observable in the current module."

Then: "If the package specified by exports is observable in the current 
module, then at least one compilation unit containing a declaration of 
the package must be observable in the current module, or a compile-time 
error occurs."

"observable in the current module" needs to be reworded, but I hope you 
can see the intent.

> If MX exports P only to MY, can MY export the same package to other
> modules?

No, because MY's exports can only utter the name of a package declared 
in MY. If MY declared its own package called P, then MY cannot read MX 
by the rules of the JPMS (as appealed to by 7.4.3).

Alex