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@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@sputstik jigsaw]$
If I run javac on the latter class it completes ok:
[adinn@sputstik jigsaw]$ javac jdk/internal/Test.java
[adinn@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@sputstik jigsaw]$ java jdk.internal.Test
Error: Could not find or load main class jdk.internal.Test
[adinn@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
