Way to bypass "uniquely visible" check for named vs. unnamed module conflict?

[Alex Buckley]

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