2

The openjdk document "JEP 261: Module System" states that:

"A related option, -Xbootclasspath/a, allows files and directories to be appended to the default bootstrap class path. This option, and the related API in the java.lang.instrument package, is sometimes used by instrumentation agents, so for compatibility it is still supported at run time.

Its value, if specified, is reported via the JDK-specific system property jdk.boot.class.path.append."

However, when I try to use this feature, it does not work. Specifically, I am using Java Agents to do instrumentation.

All works fine on JDK7 & JDK8. On JDK9+ the -Xbootclasspath/a seems to work ok, but the system property jdk.boot.class.path.append is always null.

On java 7/8:

String bootclasspath = System.getProperty(`sun.boot.class.path`);

works as expected.

On java 9:

String bootclasspath = System.getProperty("jdk.boot.class.path.append");

always return null string.

I added some debug code to dump all the system properties, and there appears to be no such property.

I have tried jdk-9.0.4 and jdk-11.0.3 with similar results.

Any ideas on how to get the bootclasspath on JDK9+?

Dileepa Nipun Salinda
  • 374
  • 5
  • 29
Mark Roberts
  • 101
  • 4
  • I suspect this comment is related to the problem: "The javac compiler only supports the -Xbootclasspath option in legacy mode"; from elsewhere in the document "Legacy mode is enabled when the compilation environment, as defined by the -source, -target, and --release options, is less than or equal to 8. None of the modular options described above may be used." – Powerlord May 25 '19 at 07:40
  • 2
    The system property "jdk.boot.class.path.append" can be read by JVMTI agents using the JVMTI GetSystemProperty function, it is not available to java agents. – Alan Bateman May 25 '19 at 12:23
  • 1
    I think it would help this question to understand why your java agent needs to know the value of -Xbootclasspath/a. The only reason it is exposed to JVMTI agents is because of VM startup issue where the value may be useful in the onload phase. Java agents can't be started until the VM is fully initialized. – Alan Bateman May 26 '19 at 14:14
  • Good point. I did not author the code in question, but my understanding is as follows: Our test generation/instrumentation tool (https://randoop.github.io/randoop) allows the user to specify alternative methods for Java runtime methods. This is primarily to allow replacements for java.awt and javax.swing to turn off dialog boxes so testing can be run unattended. Since some calls to these routines are dynamically generated they are associated with the bootstrap loader. This means the replacement classes must also be loaded by the bootstrap loader for class/name resolution to work. – Mark Roberts May 27 '19 at 15:39
  • We want to verify that the replacement methods exist before the testing starts so we look down each component of the boot class path to see if a matching class exists. Perhaps there is an alternative way to do this? The point is to have a missing replacement method fail at startup rather than the first time it is actually invoked. – Mark Roberts May 27 '19 at 15:43
  • 1
    It sounds like you should be use core reflection to introspect the modified classes. Also note that java agents can specify the Boot-Class-Path attribute in the agent JAR file so you don't need to use -Xbootclasspath/a. They can also add to the boot class loader search via the Instrumentation API. – Alan Bateman May 28 '19 at 05:56
  • But *appending* to the bootstrap path is not sufficient to *replace* classes, as the original classes are found before any path entry appended to the search path is ever examined. – Holger Jun 05 '19 at 12:09

0 Answers0