feat: always return ExtendedOpenTelemetry when incubator is available

[zeitlinger]

this is the behavior we have for other extended classes and a first step towards #7961

[codecov]

Codecov Report

❌ Patch coverage is 88.67925% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.14%. Comparing base (a12c69f) to head (495f2af).

Files with missing lines	Patch %	Lines
...main/java/io/opentelemetry/sdk/IncubatingUtil.java	76.47%	4 Missing ⚠️
...ubator/fileconfig/OpenTelemetrySdkBuilderUtil.java	71.42%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7991      +/-   ##
============================================
- Coverage     90.17%   90.14%   -0.04%     
- Complexity     7478     7486       +8     
============================================
  Files           836      838       +2     
  Lines         22550    22592      +42     
  Branches       2224     2226       +2     
============================================
+ Hits          20335    20365      +30     
- Misses         1513     1524      +11     
- Partials        702      703       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jack-berg]

Unused and a duplicate of ConfigProvider#noop()

[zeitlinger]

Called from https://github.com/zeitlinger/opentelemetry-java/blob/0db77eb839b0af1e7f32b0f7ced29e60edcce005/sdk/all/src/main/java/io/opentelemetry/sdk/IncubatingUtil.java#L26 to get an instance for ExtendedOpenTelemetrySdk.

I tried to make it return SdkConfigProvider - but then a design test failed.

[zeitlinger]

Called from https://github.com/zeitlinger/opentelemetry-java/blob/0db77eb839b0af1e7f32b0f7ced29e60edcce005/sdk/all/src/main/java/io/opentelemetry/sdk/IncubatingUtil.java#L26 to get an instance for ExtendedOpenTelemetrySdk.

I tried to make it return SdkConfigProvider - but then a design test failed.

[jack-berg]

This change isn't strictly necessary is it since the test code could still call ExtendedOpenTelemetrySdk.create(..)? Not suggesting reverting - just trying to confirm my understanding.

[zeitlinger]

see #7991 (comment)

[jack-berg]

IIUC, the benefit for this PR for callers is that now whenever opentelemetry-api-incubator is on the classpath, OpenTelemetrySdk.builder().build() will return an instance of ExtendedOpenTelemetrySdk.

[zeitlinger]

IIUC, the benefit for this PR for callers is that now whenever opentelemetry-api-incubator is on the classpath, OpenTelemetrySdk.builder().build() will return an instance of ExtendedOpenTelemetrySdk.

Yes that has benefits

• it's a consistent pattern towards stability
• you can't abuse instanceof ExtendedOpenTelemetry to check for declarative config (I did this mistake in the agent and that broke when we also used ExtendedOpenTelemetrySdk for non-declarative config)

[jack-berg]

I think we can go even further to align ExtendedOpenTelemetrySdk, SdkConfigProvider with the patterns we use in this repo for experimental features. Here's a PR to the source branch of this PR which shows how we might accomplish this by moving ExtendedOpenTelemetrySdk, SdkConfigProvidert to the opentelemetry-sdk package.

I think long term, we end up with a opentelemetry-sdk-config package analog to opentelemetry-sdk-metrics, etc. And this is a step in that direction. But there is still an open question of how that would work when the declarative config code depends on jackson, and of course we don't want to require all SDK users to require a jackson dependency. Maybe we structure the module / API in such a way where its a "bring your own jackson" situation, and you unlock additional features by opting into jackson, but basic functionality works without it. That's a different conversation though.