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
