Protobuf 3.25.5 support for Quarkus Compatibility

[umutsahin]

Hi there,

First of all I must say I just did a PoC with Valkey Cluster (bitnami chart) with Jedis forked client and results look amazing.
I was wondering to test valkey-glide and its features well with quarkus, but I am not able to use it due to version incompatibility since quarkus using 3.25.5 right now.

I was thinking if I would be able to compile glide with libprotoc 25.5 so that I would be able to test it.
But I am not able to build it successfully so far. Can you guide me even if I am able to compile it, will it be possible to use the client ?

Thanks!

[barshaul]

@Yury-Fridlyand @yipin-chen @jonathanl-bq
Can you please give your input here?
Since it seems to be a recurrent issue, is there a different workaround here to to resolve these kind of conflicts in Java? I found shading (maven-shade-plugin/com.github.johnrengelman.shadow) or a custom ClassLoader as options, do you have any insights here? shadowing the dependency name sounds like it can be a valid option, do you have any experience with it?

[yipin-chen]

The reason for using protoc version v26.0 or above is that older versions of protobuf were missing the Automatic-Module-Name entry (see protocolbuffers/protobuf#12639). This is why we made the changes in PR #1237 to define the minimum supported versions for all wrappers.

[avifenesh]

@yipin-chen we have issues with the strict netty and protobuf dependencies a lot.
Why can't we utilize Maven an Gradle shadow plugins to resolve it within our own jar?
Its blocking many users and solving it should be a top priority.
@Yury-Fridlyand @jonathanl-bq please give your input.

@asafpamzn - please lets give the JAR hell priority, and find a solution, we can't be so limited, its recurring constantly.

[Yury-Fridlyand]

Shadowing jars is a working solution. We need to make a decision which dependencies to be shadowed, and how that package will be released.

[avifenesh]

netty and protobuff are clear ones.

[yipin-chen]

We have created issue #2961 to address and track this discussion.

[umutsahin]

@yipin-chen much appreciated!

[avifenesh]

@Yury-Fridlyand The proto is done right?

[Yury-Fridlyand]

Yes, protobuf is shadowed in 1.3, but isn't relocated. Unfortunately, relocation appears to be a breaking change. So I can't say that shadowing is complete.

[avifenesh]

For the less smart audience (me), users will still have issues if having different versions?

[Yury-Fridlyand]

Unfortunately, yes. It would depend on which Jar was listed first in the classpath. GLIDE jar should be the last to ensure no collisions occur, but you should not rely on this behaviour. Relocating is how you protect against this.

[jduo]

To be more precise, the first time a (fully-qualified) class is referenced, it searches all JARs are your class path in the order they appear for the class. So if you have a protobuf JAR at the front, but a class referenced by GLIDE doesn't exist in that protobuf JAR, the class definition from within the GLIDE JAR would get used.

Relocation is much better for preventing collisions. Just creating the uber JAR doesn't solve collisions.

[avifenesh]

I see. So it will be just in 2.0. Okay.

[avifenesh]

@prateek-kumar-improving please add this as well and close.

[prateek-kumar-improving]

The problem being discussed in this discussion is covered in a common issue: #3402. Mentioning this discussion there for reference and closing this issue now.