Building OpenJDK fails with this boot JDK:
$ javac -fullversion
javac full version "1.9.0-ea-b54"
The output of the build is attached. The errors are like this:
/usr/local/home/lahvac/src/jdk/tl.precommit/hotspot/agent/src/share/classes/sun/jvm/hotspot/gc/cms/CMSBitMap.java:77: error: reference to VirtualSpace is ambiguous
public VirtualSpace virtualSpace() {
^
both class sun.jvm.hotspot.runtime.VirtualSpace in sun.jvm.hotspot.runtime and class sun.jvm.hotspot.memory.VirtualSpace in sun.jvm.hotspot.memory match
This is what I think is going on:
-VirtualSpace (and other classes) has been moved from agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java to agent/src/share/classes/sun/jvm/hotspot/memory/VirtualSpace.java (JDK-8068352).
-CMSBitMap.java (and other classes) uses import-on-demand from both these packages:
import sun.jvm.hotspot.memory.*;
import sun.jvm.hotspot.runtime.*;
-most, if not all, JDK classes are now visible on the default javac bootclasspath (after the Modular Run-Time Images, the various jar files in the JDK image have been folded into the jimage files, and since then all these classes are part of the default javac's bootclasspath)
-so javac finds the VirtualSpace class in both the old package (reading it from the boot JDK) and in the new package (reading it from the source file). This causes the clash in import-on-demand.
Maybe it would be possible to specify a -bootclasspath when building the hotspot/agent to compile against a known bootclasspath content? (This would presumably be in hotspot/make/linux/makefiles/sa.make and alike).
$ javac -fullversion
javac full version "1.9.0-ea-b54"
The output of the build is attached. The errors are like this:
/usr/local/home/lahvac/src/jdk/tl.precommit/hotspot/agent/src/share/classes/sun/jvm/hotspot/gc/cms/CMSBitMap.java:77: error: reference to VirtualSpace is ambiguous
public VirtualSpace virtualSpace() {
^
both class sun.jvm.hotspot.runtime.VirtualSpace in sun.jvm.hotspot.runtime and class sun.jvm.hotspot.memory.VirtualSpace in sun.jvm.hotspot.memory match
This is what I think is going on:
-VirtualSpace (and other classes) has been moved from agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualSpace.java to agent/src/share/classes/sun/jvm/hotspot/memory/VirtualSpace.java (
-CMSBitMap.java (and other classes) uses import-on-demand from both these packages:
import sun.jvm.hotspot.memory.*;
import sun.jvm.hotspot.runtime.*;
-most, if not all, JDK classes are now visible on the default javac bootclasspath (after the Modular Run-Time Images, the various jar files in the JDK image have been folded into the jimage files, and since then all these classes are part of the default javac's bootclasspath)
-so javac finds the VirtualSpace class in both the old package (reading it from the boot JDK) and in the new package (reading it from the source file). This causes the clash in import-on-demand.
Maybe it would be possible to specify a -bootclasspath when building the hotspot/agent to compile against a known bootclasspath content? (This would presumably be in hotspot/make/linux/makefiles/sa.make and alike).