OpenTelemetry version not defined in version management leads to NoSuchMethodException

[Carst-Tankink]

Describe the bug
Opening a JDBC connection to a spanner database throws the exception:

java.lang.NoSuchMethodError: 'io.opentelemetry.api.metrics.LongHistogramBuilder io.opentelemetry.api.metrics.LongHistogramBuilder.setExplicitBucketBoundariesAdvice(java.util.List)'
	at com.google.cloud.spanner.jdbc.Metrics.<init>(Metrics.java:46) ~[google-cloud-spanner-jdbc-2.19.3.jar:2.19.3]
	at com.google.cloud.spanner.jdbc.JdbcConnection.<init>(JdbcConnection.java:105) ~[google-cloud-spanner-jdbc-2.19.3.jar:2.19.3]
	at com.google.cloud.spanner.jdbc.JdbcDriver.connect(JdbcDriver.java:208) ~[google-cloud-spanner-jdbc-2.19.3.jar:2.19.3]

It looks like google-cloud-spanner-jdbc 2.19.3 uses the setExplicitBucketBoundariesAdvice which is only available since version 1.32.0 of opentelemetry-api (see javadoc at https://javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/metrics/LongHistogramBuilder.html), but Spring boot 3.2 provides opentelemetry-api version 1.31.0 (see https://github.com/spring-projects/spring-boot/blob/3.2.x/spring-boot-project/spring-boot-dependencies/build.gradle#L1103).

I am not 100% sure if spanner-jdbc is intended to be part of the spring-cloud-gcp offering or if it is included in my dependency chain, but I am worried about version divergence in case I start managing spanner-jdbc myself (because we do use other spanner modules from the spring-cloud-gcp project).

Versions:

• spring-cloud-gcp 5.4.2
• spring-boot 3.2.7

I observed the problem in spring-cloud-gcp 5.4.1 as well, but went to the latest available to make sure it wasn't fixed already.

Sample
See https://github.com/Carst-Tankink/spanner-jdbc-incompatible-example for a self-contained example, based on existing spanner-JDBC sample code and the spring-cloud-gcp starter.

I expect this application to start up and the /timestamp endpoint to properly connect to spanner and execute the query (provided a spanner database is created).

[burkedavison]

As an immediate workaround: the OpenTelemetry version can be explicitly defined in the application's pom.xml, and will take precedence over the version being provided by Spring Boot.

---

Although opentelemetry is defined in java-shared-dependencies' third-party-dependencies for use by projects like spanner-jdbc, the libraries-bom does not include third-party-dependencies and opentelemetry is also not listed in spring-cloud-gcp-dependencies. The result is that Spring Boot's dependency management controls the opentelemetry version.

Some options:

• Define opentelemetry in spring-cloud-gcp-dependencies
• Include third-party-dependencies with libraries-bom

Note: @breun has expressed concern with the above two options. Alternatives are discussed below.

CC @suztomo, @blakeli0

[Carst-Tankink]

Thanks for looking at this!

I forgot to add the workaround, indeed. For me this is not immediately blocking because of it, but a report seemed like a good idea regardless :)

[breun]

Spring Cloud GCP overriding Spring Boot's dependency management sounds dangerous to me, because it could cause issues, confusion and other problems for Spring Boot users. Spring Boot documentation about observation might no longer apply as-is for instance. I'd say that ideally it should be possible to add Spring Cloud GCP to project with a compatible version of Spring Boot, without Spring Cloud GCP causing changes in versions of dependencies managed by Spring Boot.

[breun]

Maybe google-cloud-spanner-jdbc could be modified to not require this method that wasn't there yet in OpenTelemetry 1.31.0? Alternatively Spring Cloud GCP 5 (which claims compatibility with Spring Boot 3.2.x) could maybe use an older version of google-cloud-spanner-jdbc that is compatible with with OpenTelemetry 1.31.0 as managed by Spring Boot 3.2.

[burkedavison]

@breun : I've updated my comment above to point to your concerns. When Tomo and Blake get back from vacation, we'll discuss the options you've provided.

[zhumin8]

This is resolved in #3146