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

[Jonathan Gibbons]

Bug filed:

https://bugs.openjdk.java.net/browse/JDK-8215739

-- Jon


On 12/20/2018 11:46 AM, Alex Buckley wrote:
> Thank you Stephan. We're looking into javac now.
>
> (BTW I enjoyed your comment on SO that "Adding module-info.java is not 
> part of the problem, but part of the solution (thereby moving your 
> code from classpath to modulepath)".)
>
> Alex
>
> On 12/20/2018 5:21 AM, Stephan Herrmann wrote:
>> Sorry, if that part was left implicit.
>> Yes, all versions of javac that I tried accept all four invocations.
>> This includes the following builds:
>> - 9.0.4+11
>> - 10.0.1+10
>> - 11.0.1+13-LTS
>> - 12-ea+19
>>
>> Stephan
>>
>>
>> On 20.12.18 00:05, Alex Buckley wrote:
>>> 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
>>>>
>>