Thanks for confirming!
Stephan
On 18.12.18 21:38, Alex Buckley wrote:
On 12/18/2018 11:04 AM, Stephan Herrmann wrote:
This has been discussed on StackOverflow in threads like
https://stackoverflow.com/q/51094274/4611488
The question can be simplified like this:
//---
import javax.xml.transform.Transformer;
public class Test {
Transformer transformer;
}
//---
Which of the following compiler invocations should accept / reject the
program:
$ javac Test.java
$ javac -classpath xml-apis-1.4.01.jar Test.java
$ javac -classpath xml-apis-1.4.01.jar
--limit-modules=java.base,java.xml Test.java
$ javac -classpath xml-apis-1.4.01.jar --limit-modules=java.base Test.java
From my understanding, only the first and the last invocations
should succeed. In both other cases the code in Test.java (associated
to the unnamed module) can access package javax.xml.transform both
from module java.xml and from the unnamed module containing
xml-apis-1.4.01.jar. (I say "the unnamed module" but I don't seen any
impact if an implementation would choose to support several unnamed
modules).
I agree that only the first and last invocations should succeed.
As you described in an Eclipse bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928), the qualified type name
`javax.xml.transform.Transformer` mentions a package `javax.xml` that is NOT uniquely visible. In particular, and assuming a single
unnamed module: when compiling an ordinary compilation unit (Test.java) associated with the unnamed module (the classpath), there IS
an ordinary compilation unit (some file in xml-apis-1.4.01.jar) associated with the unnamed module which contains a declaration of
the package; but the unnamed module also reads the java.xml module that exports the package to the unnamed module.
tl;dr A package split between the classpath and the system image is just as bad as a package split between two modules on the
modulepath.
Alex
