Confusing disparity in behaviour from javac
Andrew Dinn
adinn at redhat.com
Wed Oct 26 11:35:47 UTC 2016
I am confused by the way javac treats attempts to compile code whose
package clashes with JDK module ownership. This may be a known
'feature' but here's the symptoms and why I am concerned by them.
Consider these two classes:
1) Class Test in java.lang
package java.lang;
public class Test {
public static void main(String... args){}
}
2) Class Test in jdk.internal
package jdk.internal;
public class Test {
public static void main(String... args){}
}
If I run javac on the former class I get this:
[adinn at sputstik jigsaw]$ javac java/lang/Test.java
java/lang/Test.java:1: error: package exists in another module: java.base
package java.lang;
^
1 error
[adinn at sputstik jigsaw]$
If I run javac on the latter class it completes ok:
[adinn at sputstik jigsaw]$ javac jdk/internal/Test.java
[adinn at sputstik jigsaw]$
I believe the key difference here is that java.lang is exported and
jdk.internal is not. Is that what causes this disparity in outcome?
Whatever the reason for the different response the fact that there is no
compile time error (or warning) in the latter case is problematic
because when I try next to execute the compiled code I /do/
get an error:
[adinn at sputstik jigsaw]$ java jdk.internal.Test
Error: Could not find or load main class jdk.internal.Test
[adinn at sputstik jigsaw]$
If the problem is that this package has already been bagged by the JDK
then should javac not report that?
This may sound like a ludicrous example since no one is likely to create
a class called java.lang.Test or jdk.internal.Test. However, the
original problem which led to it was when someone tried to compile code
for class sun.applet.Test. The runtime error was far from obvious since
file sun/applet/Test.class was sitting there in the classpath.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the jigsaw-dev
mailing list