[feature request] Support the environment variable propagation spec in java

[adrielp]

Related Problems?

With the environment variable context propagation spec being added, we'd like to have its support added to Java. This is part of a larger effort to adding support in each of the currently supported languages.

Describe the solution you'd like:

I'd like the specification implemented in Java.

Considered Alternatives

n/a

Additional Context

No response

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[jack-berg]

PRs welcome!

[Bhagirath00]

@jack-berg @trask I’d like to work on this feature and contribute a Java implementation aligned with the updated environment variable context propagation spec.

I have the project set up locally and am going through similar implementations in the SDK. If there’s a preferred approach or anything I should be aware of, I’d appreciate guidance.

Happy to submit a PR once aligned.

[Bhagirath00]

Hey @jkwatson @trask @jack-berg I've gone through the environment variable context propagation spec in detail. The spec describes two implementation approaches:

Approach 1 — A dedicated EnvironmentContextPropagator that decorates the TextMapPropagator
(used by Swift)

Approach 2 — Provide EnvironmentGetter and EnvironmentSetter carriers that work with the existing TextMapPropagator
(used by Go and Python)

Which approach would you prefer for Java? Also, which module should this live in — api/incubator, sdk-extensions/incubator, or somewhere else?

[jkwatson]

Hey @jkwatson @trask @jack-berg I've gone through the environment variable context propagation spec in detail. The spec describes two implementation approaches:

Approach 1 — A dedicated EnvironmentContextPropagator that decorates the TextMapPropagator (used by Swift)

Approach 2 — Provide EnvironmentGetter and EnvironmentSetter carriers that work with the existing TextMapPropagator (used by Go and Python)

Which approach would you prefer for Java? Also, which module should this live in — api/incubator, sdk-extensions/incubator, or somewhere else?

My hunch is that approach 2 is the right way to go, but I don't feel strongly about it.

[jack-berg]

Which approach would you prefer for Java? Also, which module should this live in — api/incubator, sdk-extensions/incubator, or somewhere else?

Should be either 1. /api/incubator or 2. /extensions/trace-propagators (in an internal package until the spec stabilizes).

I want to say 1 because I think the final home for this (once the spec stabilizes) will be /api/all. /extensions/trace-propagators doesn't seem like the appropriate final home because all the propagators there are for compatibility with other tracing systems (ot, jaeger, b3), where as the w3c trace and baggage propagators live in /api/all. This seems more like w3c trace and bagage than ot / jaeger / b3.

[Bhagirath00]

Hey @jack-berg @jkwatson, I've just submitted a PR for this!
I implemented the requested carriers in api/incubator and verified them with unit tests. Looking forward to your feedback!