Runtime attach enhancements for JDK 21+

[breedx-splk]

Reference: https://mail.openjdk.org/pipermail/jigsaw-dev/2023-March/014816.html

The intention is to disable allowing dynamic attach of agents by default starting with Java 21. The runtime attach component should at a minimum enhance the README to mention the newly required JVM commandline arg. It would also be great to have a test/example to cover this use and demonstrate that it [still] works after 21.

[trask]

I'm curious if Launcher-Agent-Class works (or if we can get it to work).

[breedx-splk]

I've never used that mechanism, but having spent 41 seconds reading about it it sounds like Launcher-Agent-Class is still something that happens at "startup time" or something early in the lifecycle, vs. a much later dynamic attach. I can't reckon how it's related to dynamic attach. What am I missing?

[trask]

our use of dynamic attach is already limited to "very early in the lifecycle".

so I'm thinking in our case, they both seem to address the same use case "how do I bundle up the OTel Javaagent inside of my application"

(I also only just learned about Launcher-Agent-Class when reading the link above)

[tylerbenson]

Related: https://openjdk.org/jeps/451

[jeanbisutti]

The runtime attachment of the Java agent still works with Java 21 with this warning:

WARNING: A Java agent has been loaded dynamically (C:\..\Temp\otel-agent6673307005713919434\agent.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release

[jeanbisutti]

It would also be great to have a test/example to cover this use and demonstrate that it [still] works after 21.

The smoke tests of the OTel Java instrumentation repo seem well suited to do this. Could the runtime attach component be moved to the instrumentation repo?

[trask]

It looks like we've discussed this in the past 😄

2022/7/8 meeting:

• “Top-level deployment options” could all live in instrumentation repo
  • Javaagent
  • Spring boot starters
  • Runtime attach
  • Static instrumentation

2022/10/13 meeting:

• Move runtime attach to instrumentation repository
  • In particular to leverage smoke tests:
    • https://github.com/open-telemetry/opentelemetry-java-contrib/issues/508

I'm supportive of this.

Can you open an issue in the opentelemetry-java-instrumentation repo to propose this?

[jeanbisutti]

It looks like we've discussed this in the past 😄

2022/7/8 meeting:

• “Top-level deployment options” could all live in instrumentation repo

  • Javaagent
  • Spring boot starters
  • Runtime attach
  • Static instrumentation

2022/10/13 meeting:

• Move runtime attach to instrumentation repository

  • In particular to leverage smoke tests:

    • No Class in opentelemetry-runtime-attach jar #508

I'm supportive of this.

Can you open an issue in the opentelemetry-java-instrumentation repo to propose this?

Issue created in the Java instrumenation repository: https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/9745