WARNING: sun.reflect.Reflection.getCallerClass is not supported.

[OrangeDog]

I think this is coming from the shaded log4j2:

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
2020-07-15 12:07:23,145 [Attach Listener] INFO  co.elastic.apm.agent.util.JmxUtils - Found JVM-specific OperatingSystemMXBean interface: com.sun.management.OperatingSystemMXBean
2020-07-15 12:07:24,456 [Attach Listener] INFO  co.elastic.apm.agent.configuration.StartupInfo - Starting Elastic APM 1.17.0 as MyApp on Java 11.0.7 (Ubuntu) Linux 5.4.0-40-generic
2020-07-15 12:07:24,502 [Attach Listener] INFO  co.elastic.apm.agent.impl.ElasticApmTracer - Tracer switched to RUNNING state

[felixbarny]

That's probably due to our shading configuration in regards to multi-release jars.

See also https://stackoverflow.com/questions/53049346/is-log4j2-compatible-with-java-11

[eyalkoren]

Thanks for reporting!
We already started a multi-step architectural change of the agent (#1230 is the first step), that will eventually enable us to package and load agent classes entirely differently from the current way.
Once we get there, we intend to stop shading dependencies. In addition, we intend to load classes from a dedicated class loader that can handle multi-version classes better.
Please keep on following the progress and testing new versions as they are released, and let us know if we fail to eliminate this warning 🙂

[SylvainJuge]

This issue is still present in latest versions of the agent (1.28.x as of writing):

WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
[main] INFO  co.elastic.apm.agent.util.JmxUtils - Found JVM-specific OperatingSystemMXBean interface: com.sun.management.OperatingSystemMXBean
[main] INFO  co.elastic.apm.agent.configuration.StartupInfo - Starting Elastic APM 1.28.5-SNAPSHOT.UNKNOWN as opbeans (0.0.1-SNAPSHOT) on Java 11.0.8 Runtime version: 11.0.8+10 VM version: 11.0.8+10 (AdoptOpenJDK) Linux 5.13.0-27-generic

[felixbarny]

There are two issues

1. We exclude META-INF/versions/** via our maven shade config (easy to fix)
2. ShadedClassLoader doesn't support loading multi-release jars (not quite so easy to fix but should be doable)

[felixbarny]

To add some context: log4j has two implementations for org.apache.logging.log4j.util.StackLocator. One default implementation and another one for Java 9+ which is loaded via a multi-release jar.

log4j.jar
+ META-INF
|  \- versions/9
|     \- org/apache/logging/log4j/util
|        \- StackLocator.class          <- loaded on Java 9+
\- org/apache/logging/log4j/util
  \- StackLocator.class              <- default (Java 8 and lower)

We'd need to enhance ShadedClassLoader so it can load these from elastic-apm-agent.jar!/agent/META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.esclazz.

One option would be to load the resources via a JarFile::getJarEntry as this supports loading from a multi-release jar. However, there may be issues with class loaders that override the stream handler for the jar protocol.

As the agent jar is added to the system class loader, we could also investigate whether delegating the resource lookup to the system class loader would work.

[felixbarny]

After some more investigation, I don't think the ShadedClassLoader is the issue. One easy thing that's missing is the Multi-Release: true manifest attribute.

Another issue is that we package the META-INF dir under the agent dir:

elastic-apm-agent.jar
\- agent
   \- META-INF
      \- versions/9
         \- org/apache/logging/log4j/util
            \- StackLocator.esclazz

But we should package it under the top-level META-INF folder.

elastic-apm-agent.jar
\- META-INF
   \- versions/9
      \- agent/org/apache/logging/log4j/util
         \- StackLocator.esclazz