-
Bug
-
Resolution: Unresolved
-
P4
-
9, 10, 20
-
generic
-
generic
When running e.g.:
java -javaagent:jHiccup.jar -jar target/benchmarks.jar
on OpenJDK 8, the java.class.path system property shows:
target/benchmarks.jar:jHiccup.jar
on OpenJDK 10, OpenJDK 11 EA (build 11-ea+23) and OpenJDK 12 EA (build 12-ea+3) it shows only:
target/benchmarks.jar
This prevents e.g. agents forking additional processes using their jars. Without the java.class.path system property properly reflecting java agent jar paths, There is [currently] no apparent alternative for determining the path to the javaagent jar from within the running program. [correction: there is an alternative means of detemining the path, as used in the following workaround: https://github.com/giltene/jHiccup/commit/d0aa858fe6e4024042cc96bb618c5b885b405c7b )
E.g. the -c option (launching control process to log system-level hiccups on an otherwise idle JVM) of jHiccup (see README at https://github.com/giltene/jHiccup, and the source code that uses java.class.path in constructing the control process command line at https://github.com/giltene/jHiccup/blob/394c586572d15b88e585923d398968ee4bc59ac6/src/main/java/org/jhiccup/HiccupMeter.java#L308) currently does not work post-java-8 because of this bug, and has no known workaround alternatives.
Fixing the Java 9+ java-class-path behavior to match that of java 8, or alternatively presenting a new system property that would list the jars of java agents (e.g. "java.agents.path"?) would provide the needed information for agents to be able to properly use their jars in parameters forked processes.
java -javaagent:jHiccup.jar -jar target/benchmarks.jar
on OpenJDK 8, the java.class.path system property shows:
target/benchmarks.jar:jHiccup.jar
on OpenJDK 10, OpenJDK 11 EA (build 11-ea+23) and OpenJDK 12 EA (build 12-ea+3) it shows only:
target/benchmarks.jar
This prevents e.g. agents forking additional processes using their jars. Without the java.class.path system property properly reflecting java agent jar paths, There is [currently] no apparent alternative for determining the path to the javaagent jar from within the running program. [correction: there is an alternative means of detemining the path, as used in the following workaround: https://github.com/giltene/jHiccup/commit/d0aa858fe6e4024042cc96bb618c5b885b405c7b )
E.g. the -c option (launching control process to log system-level hiccups on an otherwise idle JVM) of jHiccup (see README at https://github.com/giltene/jHiccup, and the source code that uses java.class.path in constructing the control process command line at https://github.com/giltene/jHiccup/blob/394c586572d15b88e585923d398968ee4bc59ac6/src/main/java/org/jhiccup/HiccupMeter.java#L308) currently does not work post-java-8 because of this bug, and has no known workaround alternatives.
Fixing the Java 9+ java-class-path behavior to match that of java 8, or alternatively presenting a new system property that would list the jars of java agents (e.g. "java.agents.path"?) would provide the needed information for agents to be able to properly use their jars in parameters forked processes.
- relates to
-
JDK-8160950 Agent JAR added to app class loader rather than system class loader when running with -Djava.system.class.loader
-
- Closed
-