fix(deps): update dependency com.google.protobuf:protobuf-java to v4

[renovate[bot]]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
com.google.protobuf:protobuf-java (source)	3.25.3 -> 4.26.1

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• [ ] If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[snazy]

Need to wait for the gRPC dependencies to be updated as well, with updated dependencies like com.google.api.grpc:proto-google-common-protos supporting protobuf v4.

[pkwarren]

Need to wait for the gRPC dependencies to be updated as well, with updated dependencies like com.google.api.grpc:proto-google-common-protos supporting protobuf v4.

Any idea on if/when these dependencies are planning to upgrade? I'm guessing it will be a breaking change for both upstream projects so it might take a while for them to adopt protobuf v4 Java libraries.

I didn't see either of those listed as dependencies of cel-core. Until cel-java updates, we're blocked on updating the downstream bufbuild/protovalidate-java project, thus blocking adoption of protobuf v4 in other consumers.

If you're ok with it, I'm happy to prepare a PR to update this project to protobuf v4 since there are build failures in the renovate PR.

[snazy]

Need to wait for the gRPC dependencies to be updated as well, with updated dependencies like com.google.api.grpc:proto-google-common-protos supporting protobuf v4.

Any idea on if/when these dependencies are planning to upgrade? I'm guessing it will be a breaking change for both upstream projects so it might take a while for them to adopt protobuf v4 Java libraries.

I didn't see either of those listed as dependencies of cel-core. Until cel-java updates, we're blocked on updating the downstream bufbuild/protovalidate-java project, thus blocking adoption of protobuf v4 in other consumers.

If you're ok with it, I'm happy to prepare a PR to update this project to protobuf v4 since there are build failures in the renovate PR.

Yes & yes :)

The build failures are due to gRPC vs protobuf v4 for the conformance tests. Maybe it's a little change - IDK.

CEL itself does not really rely on the protobuf version. However classes generated generated w/ v4 don't work with v3 and vice versa (the "usual" protobuf compatibility game).

We usually use the cel-standalone artifact, which doesn't expose protobuf - but classes in cel-core refer to protobuf classes (because CEL itself heavily relies on protobuf).

I don't see a particular reason to not bump to v4 - it's rather just work.

[pkwarren]

Based on https://github.com/grpc/grpc-java/issues/11015#issuecomment-2000234497 it sounds like adoption upstream will likely be a ways off.

[snazy]

Yea - that comment sounds... "terrible" is probably the right word there.

[snazy]

@pkwarren I'm not sure how you use CEL-Java, but maybe you can get away with a (re)serailization layer and using the cel-standalone artifact? I.e. serialize the protobuf4 and deserialize using the relocated protobuf in cel-standalone? It feels hacky and awkward tho.

[snazy]

(There are a lot of dependencies to googleapis et al that are part of the public CEL-Java-API - so even the bump to protobuf v4 would be a breaking change for CEL-Java as well ... :facepalm: )

[renovate[bot]]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 4.x releases. But if you manually upgrade to 4.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.