Summary
The root POM manages protobuf-java at 3.25.5. Upgrading to 4.x (the current stable line) is blocked by the project's gRPC dependency. This issue surfaces the dependency graph and proposes a coordinated upgrade path.
Current state
| Artifact |
Version |
Protobuf compiled against |
protobuf-java (managed) |
3.25.5 |
— |
io.grpc:grpc-protobuf (via GreptimeDB ingester) |
1.56.1 |
3.22.3 |
io.grpc:grpc-protobuf (latest gRPC release) |
1.73.0 |
3.25.5 |
grpc-protobuf:1.56.1 is pulled in transitively by hertzbeat-warehouse via io.greptime:ingester-grpc:0.11.0. Within the 3.x line this is safe — code compiled against 3.22.3 runs on 3.25.5 without issue. The concern is crossing the 3.x → 4.x boundary.
Why protobuf 4.x is blocked
protobuf-java 4.x introduced RuntimeVersion.validateProtobufGencodeVersion(), which generated code compiled with a 4.x protoc calls at class initialization. Code compiled with 3.x protoc does not have this call and is safe on a 4.x runtime.
The problem is gRPC itself. The gRPC team's latest release (1.73.0) still declares protobuf-java:3.25.5 — they have not moved to 4.x. Running gRPC 1.56.1 (compiled against 3.22.3) against a 4.x protobuf runtime is an untested configuration that the gRPC project has not validated. The risk of a ClassCastException or service descriptor mismatch at runtime is real, and unit tests would not catch it because gRPC calls are mocked.
We tested the version bump (protobuf.version=3.25.5 → 4.33.2): all modules compiled cleanly, all unit tests passed. But that result is not sufficient assurance for the gRPC path, which is exercised only at integration time against a live GreptimeDB instance.
Why this matters
Several current GCP client libraries require protobuf 4.x. For example, google-cloud-spanner-jdbc:2.31+ is compiled against protobuf 4.x. As long as the project stays on 3.x, GCP integrations must pin to older driver versions (e.g. google-cloud-spanner-jdbc:2.30.0, the last 3.x-compatible release).
Proposed upgrade path
The upgrade requires coordinating two things:
-
Upgrade gRPC to a version that explicitly supports protobuf 4.x. Based on the gRPC changelog, this is expected in the 1.7x or later series. The project would need to override the gRPC version brought in by io.greptime:ingester-grpc and verify the GreptimeDB warehouse integration still functions end-to-end.
-
Upgrade protobuf.version from 3.25.5 to 4.x once gRPC compatibility is confirmed.
mysql-connector-j:8.4.0 also depends on protobuf (for its X Protocol), but compiled against 3.x — it should run on 4.x without issue since it uses no protoc-generated RuntimeVersion checks.
Questions for maintainers
- Is the GreptimeDB ingester version (
0.11.0) likely to be upgraded soon? A newer ingester-grpc might already pull a gRPC version that supports protobuf 4.x.
- Is there an existing roadmap item for this upgrade?
- Would a PR that upgrades gRPC and protobuf together be welcome, with integration tests against a live GreptimeDB instance as evidence?
Happy to contribute the upgrade PR once there is clarity on the gRPC compatibility question.
Summary
The root POM manages
protobuf-javaat3.25.5. Upgrading to4.x(the current stable line) is blocked by the project's gRPC dependency. This issue surfaces the dependency graph and proposes a coordinated upgrade path.Current state
protobuf-java(managed)io.grpc:grpc-protobuf(via GreptimeDB ingester)io.grpc:grpc-protobuf(latest gRPC release)grpc-protobuf:1.56.1is pulled in transitively byhertzbeat-warehouseviaio.greptime:ingester-grpc:0.11.0. Within the 3.x line this is safe — code compiled against 3.22.3 runs on 3.25.5 without issue. The concern is crossing the 3.x → 4.x boundary.Why protobuf 4.x is blocked
protobuf-java 4.x introduced
RuntimeVersion.validateProtobufGencodeVersion(), which generated code compiled with a 4.x protoc calls at class initialization. Code compiled with 3.x protoc does not have this call and is safe on a 4.x runtime.The problem is gRPC itself. The gRPC team's latest release (1.73.0) still declares
protobuf-java:3.25.5— they have not moved to 4.x. Running gRPC 1.56.1 (compiled against 3.22.3) against a 4.x protobuf runtime is an untested configuration that the gRPC project has not validated. The risk of aClassCastExceptionor service descriptor mismatch at runtime is real, and unit tests would not catch it because gRPC calls are mocked.We tested the version bump (
protobuf.version=3.25.5→4.33.2): all modules compiled cleanly, all unit tests passed. But that result is not sufficient assurance for the gRPC path, which is exercised only at integration time against a live GreptimeDB instance.Why this matters
Several current GCP client libraries require protobuf 4.x. For example,
google-cloud-spanner-jdbc:2.31+is compiled against protobuf 4.x. As long as the project stays on 3.x, GCP integrations must pin to older driver versions (e.g.google-cloud-spanner-jdbc:2.30.0, the last 3.x-compatible release).Proposed upgrade path
The upgrade requires coordinating two things:
Upgrade gRPC to a version that explicitly supports protobuf 4.x. Based on the gRPC changelog, this is expected in the 1.7x or later series. The project would need to override the gRPC version brought in by
io.greptime:ingester-grpcand verify the GreptimeDB warehouse integration still functions end-to-end.Upgrade
protobuf.versionfrom3.25.5to4.xonce gRPC compatibility is confirmed.mysql-connector-j:8.4.0also depends on protobuf (for its X Protocol), but compiled against 3.x — it should run on 4.x without issue since it uses no protoc-generated RuntimeVersion checks.Questions for maintainers
0.11.0) likely to be upgraded soon? A neweringester-grpcmight already pull a gRPC version that supports protobuf 4.x.Happy to contribute the upgrade PR once there is clarity on the gRPC compatibility question.