The best telemetry starts at the source—inside the client libraries.
But in most cases, that means taking a dependency on the OpenTelemetry API from your library. And while it’s stable, minimal, reliable, and safely no-op unless configured—transitive dependencies are still the bane of any library developer’s existence, and most of us try to avoid them.

To work around this, people reach for abstractions, plugins, bridges, or even OTel forks that break context propagation. The result? A poor user experience. Users must find the right plugin, install it, wire it up—and still hit the diamond dependency problem, now it just affects a subset of users.

But what if you could take a truly optional dependency? If OpenTelemetry is on the classpath, instrumentation kicks in. If it’s not, no harm done.
How hard is that to pull off? How reliable? How performant?

Let’s explore that—through the lens of the next generation of Azure SDKs for Java. Spoiler: it’s easy and fast, and as a side-bonus, we can fall back to logs-based tracing if OTel is not found.