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

[Stephan Herrmann]

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