Mode where Javaagent puts unshaded API and SDK in the bootstrap class loader

[trask]

Revisiting https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/misc/interop-design/interop-design.md#interoperability-design, does it make sense to introduce a new mode where the Javaagent puts unshaded OpenTelemetry API and SDK in the bootstrap class loader and forces all class loaders to load them from there?

While this introduces some restrictions on interoperability, especially across any major version bumps of OpenTelemetry API, it could be nice for runtime attach users because potentially that would allow customizing the SDK via autoconfigure hooks directly in their codebase.

I think runtime attach users would particularly benefit because:

• They are already essentially pinning a version of OpenTelemetry API via their runtime attach dependency, so interop across different versions is less of a concern.
• They are already able to modify main, which means they have control over the system class path, as opposed to say war file applications where it is likely too late to customize the SDK used by the Javaagent anyways.

[trask]

Potentially (if it works out) this could even be the default mode for runtime-attach.

[jeanbisutti]

They are already essentially pinning a version of OpenTelemetry API via their runtime attach dependency, so interop across different versions is less of a concern.

Today, the runtime attach dependency contains the OTel agent jar. The OTel agent is not a transitive dependency. So adding the runtime attach dependency is not enough to use the OpenTelemetry API.

[trask]

Where should Javaagent SPI live?