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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stephan Herrmann
Hi,

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

Also ecj has some issues in this area, but I want to be sure my corrections
go in the right direction.

Is javac applying some tricks like deciding that the content of xml-apis-1.4.01.jar
is not observable if that would create a conflict with a JDK module?

best,
Stephan
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
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
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: 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
>
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: 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
>>>
>
Reply | Threaded
Open this post in threaded view
|

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