Bump Java agent to 2.x with upcoming ECS alignment changes

[trask]

The upcoming HTTP semconv changes are going to be disruptive for lots of users, and I think it may justify bumping the Java agent from 1.x to 2.x to give users a really clear signal that they may need to take care when upgrading.

I'm not sure that the library instrumentations require bumping from 1.x to 2.x since they are all marked -alpha.

EDIT: also consider including http.(server|client).duration metric change from milliseconds -> seconds in the 2.x bump

[breedx-splk]

I agree that a version bump sounds like a good idea. Is there a strategy for discontinuing support for the 1.x branch then?

[tylerbenson]

Should these changes be batched with other future semconv changes before bumping the major version?

[trask]

I agree that a version bump sounds like a good idea. Is there a strategy for discontinuing support for the 1.x branch then?

A couple of options:

• Introduce a flag in 2.x that emits the prior semconv attributes
• Provide patch releases for some period of time on 1.x (patch releases are only made for regressions, security vulnerabilities, memory leaks and deadlocks

[trask]

Should these changes be batched with other future semconv changes before bumping the major version?

If other semconv changes are ready then yes, but I wouldn't want to hold up adopting the new (hopefully finally stable) HTTP semconv changes.

In general it's tricky for the Java agent since it bundles so many instrumentations together.

Technically we don't guarantee telemetry stability across minor versions of the Java agent, but given the wide usage of HTTP instrumentation and the significant changes coming to HTTP semconv, it feels worth bumping the version in this case.

[trask]

I agree that a version bump sounds like a good idea. Is there a strategy for discontinuing support for the 1.x branch then?

A couple of options:

• Introduce a flag in 2.x that emits the prior semconv attributes
• Provide patch releases for some period of time on 1.x (patch releases are only made for regressions, security vulnerabilities, memory leaks and deadlocks

One factor in deciding the approach will be the transition plan. For example if the transition plan doesn't allow for us to start emitting the new HTTP semconv by default for 6 months, then I'd probably want to add a flag to start emitting them sooner, in which case we'll have the flag support already and we can go with that option as part of sunsetting 1.x

[trask]

I updated this issue to include consideration of the http.(server|client).duration metric change from seconds -> milliseconds in the 2.x bump

[tylerbenson]

Any other major breaking changes to consider? perhaps we need a 2.0 breaking change tag?

[jack-berg]

In #8633 we propose overriding the autoconfigure behavior to revert otel.exporter.logs default from otlp to none. If we proceed, we should remove this override in the 2.x version. The affect in 2.x would be that log instrumentation is enabled by default, and otlp exporter of logs is enabled by default.

[jack-berg]

Since were also working on stabilizing JVM runtime metrics, should we bundle these changes into a 2.x as well?

[mateuszrzeszutek]

Since were also working on stabilizing JVM runtime metrics, should we bundle these changes into a 2.x as well?

Definitely 💯
I think we haven't voiced that openly, but I strongly feel that we should release the 2.x version with stable JVM metrics.

[mateuszrzeszutek]

I made a project board for tracking the work we have to do before releasing 2.0: https://github.com/orgs/open-telemetry/projects/54

Let's close this issue and use the project instead