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
