Bundled mysql-connector-j protobuf causes OpenTelemetry incompatibility

Expected behavior

A plugin that resolves protobuf-java 4.34.0 (e.g. transitively through micrometer-registry-otlp or the OTLP exporter) should be able to use it at runtime. That satisfies protobuf's runtime >= gencode rule.

Observed/Actual behavior

Paper bundles mysql-connector-j, which pulls com.google.protobuf 4.29.x onto the shared classpath. Paper's bundled copy wins over the plugin's 4.34.0, so protobuf's runtime check blows up at class init:

com.google.protobuf.RuntimeVersion$ProtobufRuntimeVersionException:
... runtime 4.29.x. Runtime version cannot be older than the linked gencode version.

This was already reported in #13835 and closed as won't fix, with relocation suggested as the workaround. I'm opening this because relocation doesn't fully work for OpenTelemetry.

Relocating OTel isn't really viable: the Java agent relies on canonical class names (io.opentelemetry., io.grpc.) to instrument libraries, and context keys can't be relocated without breaking propagation (see open-telemetry/opentelemetry-java-instrumentation#4666). Relocating just protobuf is fragile too, since it breaks as soon as a protobuf type crosses the boundary.

Steps/models to reproduce

Plugin depends on a library with Protobuf gencode ≥ 4.30 (e.g., micrometer-registry-otlp).

Plugin and Datapack List

(My plugin with Protobuf only)

[07:25:35 INFO]: [PluginInitializerManager] Paper plugins (1):

core (1.0.0-SNAPSHOT)

Paper version

This server is running Paper version 26.1.2-72-ver/26.1.2@1a6b910 (2026-06-19T13:08:47Z) (Implementing API version 26.1.2.build.72-stable)
You are running the latest version

Other

Please consider excluding protobuf-java from the bundled mysql-connector-j. A single exclude would likely be enough, for a few reasons:

1. The protobuf classes are only loaded lazily when you actually use X DevAPI, so classic JDBC connections (what basically every plugin does) should keep working without protobuf on the classpath at all.
2. With protobuf gone from Paper's runtime, there's nothing left to win over a plugin's resolved version, so the conflict wouldn't exist anymore, with no relocation or version-check workarounds needed on either side.
3. Anyone who genuinely needs X Protocol is likely already shipping mysql-connector themselves through the library loader, so they could pull protobuf in on their own rather than having it forced on everyone by default.

Start by locating how Paper bundles mysql-connector-j and declares its transitive protobuf-java dependency. Reproduce the issue with a plugin using protobuf gencode at least 4.30, such as micrometer-registry-otlp, and verify that classic JDBC use still works while the bundled protobuf is no longer forced onto the shared classpath.