don't throw class cast exception when we have a noop tracer, meter, logger

[zeitlinger]

similar to open-telemetry/opentelemetry-java-instrumentation#11934

[jkwatson]

You can't make the api depend on the incubator; that introduces a circular dependency, since the incubator depends on the api.

[zeitlinger]

You can't make the api depend on the incubator; that introduces a circular dependency, since the incubator depends on the api.

right - this is real problem because of

opentelemetry-java/api/all/src/main/java/io/opentelemetry/api/trace/TracerProvider.java

Lines 23 to 25 in 963bc38

	static TracerProvider noop() {
	return DefaultTracerProvider.getInstance();
	}

- which is in the api project

we could deprecate the method

BTW, the same issue applies to all "Extended..." apis

[codecov]

Codecov Report

Attention: Patch coverage is 97.88360% with 4 lines in your changes missing coverage. Please review.

Project coverage is 90.09%. Comparing base (1f6de35) to head (e7d7114).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...ry/api/incubator/metrics/ExtendedDefaultMeter.java	96.22%	4 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6617      +/-   ##
============================================
+ Coverage     89.99%   90.09%   +0.10%     
- Complexity     6358     6390      +32     
============================================
  Files           703      711       +8     
  Lines         19147    19333     +186     
  Branches       1889     1891       +2     
============================================
+ Hits          17231    17418     +187     
+ Misses         1337     1335       -2     
- Partials        579      580       +1     

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

[zeitlinger]

@jack-berg can you check?

[jack-berg]

Seems pretty reasonable but I wonder about:

1. Code reuse by moving existing default implementations to internal package and removing the final modifier.
2. Testing graal both with and without the incubating artifact on the class path

[jack-berg]

This is the first usage of java-test-fixtures in this repo. I kind of like it, but would be good to update otel.java-conventions.gradle.kts to include all the standard test dependencies:
https://github.com/open-telemetry/opentelemetry-java/blob/main/buildSrc/src/main/kotlin/otel.java-conventions.gradle.kts#L237-L270

[zeitlinger]

can you give me a hint how to do that? fixtures { or similar doesn't exist

[jack-berg]

What do you think about restructuring the existing default implementations to allow subclassing:

Suggested change

	final class ExtendedDefaultTracer implements ExtendedTracer {
	final class ExtendedDefaultTracer extends DefaultTracer implements ExtendedTracer {

Would have to make them public in an internal package, and more, but the payoff would be the ability to reuse code.

[zeitlinger]

it wouldn't help because the extended span builder has to return it's own (ExtendedSpanBuilder) type, so we have to implement all methods

[zeitlinger]

1. Code reuse by moving existing default implementations to internal package and removing the final modifier.

can you elaborate?

[zeitlinger]

2. Testing graal both with and without the incubating artifact on the class path

added

[zeitlinger]

thanks @jack-berg