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?
More practically, if several modules M0, M1 ... have some compilation units
which all declare package P, what's the effect if
M0 exports P
?
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?
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
?
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?
If MX exports P only to MY, can MY export the same package to other modules?
Stephan
