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

[Stephan Herrmann]

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