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

[Alex Buckley]

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
>>>
>