On 26/10/2016 12:35, Andrew Dinn wrote:
:
If the problem is that this package has already been bagged by the JDK
then should javac not report that?
When you compile code in the unnamed module then it reads java.base but
java.base doesn't export jdk.internal to anyone so there isn't an issue
at compile-time. However, at run-time you have a split package issue by
way of deploying jdk.internal.Test on the class path (for reliability
reasons, the JDK disallows splitting a package between the class path
and the modules in the boot layer, even if the module in the boot layer
is not defined to the application class loader). If jdk.internal.Test is
in a module in a custom layer or even loaded by a custom class loader
(unnamed module) then there won't be an issue. Looking at it now then we
should minimally improve the launcher handling for the corner case that
is the main class on the class path in the same package as a package in
a JDK module.
-Alan
