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

[Alex Buckley]

I'm seeing multiple claims in the SO item and the Eclipse bug that javac 
does the wrong thing, but no-one says what it is. Are you saying that 
javac (which version?) compiles Test.java in the second and third 
invocations?

Alex

On 12/18/2018 3:21 PM, Stephan Herrmann wrote:
> 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
>