On 09/13/2015 06:25 AM, Alan Bateman wrote:
On 12/09/2015 20:16, Jayaprakash Arthanareeswaran wrote:
Hello experts,
With JDK 9, some of JDT Core tests have started failing. The failing
tests
are in the JSR 199 area, where we test Eclipse's compiler in a mixed
mode
with Javac's StandardJavaFileManager.
standardJavaFileManager.getLocation(StandardLocation.PLATFORM_CLASS_PATH);
Until JDK 8, this used to return rt.jar and other jars but not
anymore. I
expected this to return the path to the bootmodules.jimage just like the
system property "sun.boot.class.path".
The proposal is to drop sun.boot.class.path, see the "Removed:
Bootstrap class-path options" in JEP 261 [1]. It wasn't been useful
since the changes for JEP 220 went into JDK 9. There are a few
remaining pieces to be done in HotSpot before we can get there, mostly
in the Serviceability Agent and the "Compile-The-World" built-in test.
The issue is tracked by JDK-8131049 and JDK-8077209.
To be consistent then I would think getLocation(PLATFORM_CLASS_PATH)
would return an empty Iterable and a getLocation(SYSTEM_MODULE_PATH),
or a Iterable<Path> variant, would return jrt:/. I'm sure Jon will
reply on this issue and explain JRT_MARKER_FILE (which I suspect is
what you are wondering about).
-Alan
[1] http://openjdk.java.net/jeps/261
There are two aspects to this.
JavaFileManager does not know the details of how it is being used, and
so it does not know whether it is being used in a "legacy" compilation
using PLATFORM_CLASS_PATH, or in a "modular" compilation" using
SYSTEM_MODULE_PATH. Therefore both the PLATFORM_CLASS_PATH and
SYSTEM_MODULE_PATH locations are defined, for use as the context dictates.
We are also updating StandardJavaFileManager to better support
Path-based locations, as well as File-based locations. JRT_MARKER_FILE
is a remnant of that transition, and that of introducing jrt-fs to JDK 8
and JDK 9.
-- Jon
