Support Protobuf Java V4+

[lockhartja]

Seems to be a breaking change with the latest release of com.google.protobuf:protobuf-java, currently this code

@Target(AnnotationTarget.CLASS)
annotation class KrotoDC(
   val forProto: KClass<out GeneratedMessageV3>
)

breaks to due to a signature change to com.google.protobuf.GeneratedMessage....

here is a link to the change announcement
[Java] The base class for generated messages will be GeneratedMessage, not GeneratedMessageV3.

any plans to version bump the dependencies?

[mscheong01]

Hi @lockhartja 👋
Thanks for informing me about this.
I'll look into the protobuf-java updates and come up with a new release sometime soon.

[pambrose]

Along the same lines, I had to add com.google.protobuf:protobuf-java-util to my build.gradle.kts after the KrotoDC 1.1.1 update. Without it, import com.google.protobuf.util.JsonFormat was breaking in the generated files.

[mscheong01]

@pambrose yes, it was added in 1.1.0 for json serialization support. I did write a heads up on the release note but it seems that I might have had to make it more noticeable 😢

[mscheong01]

I've looked into the changes and found out that grpc-java hasn't yet upgraded to protobuf-java V4 (latest version uses 3.25.1).
They seem to be unable to upgrade to v4 currently because of some major breaking changes. The progress is being tracked in this issue.
I'll keep an eye on it and get krotoDC to support v4 once grpc-java gets updated.

[mscheong01]

😃

[lockhartja]

@mscheong01 tracking the conversation -- are you able to move to the latest grpc-java...which should allow your community to move protobuf 4?

[mscheong01]

@lockhartja I've currently identified a problem where the hasOptionalKeyword method has become private, which breaks the code where we access it 🥲. I haven't had the time to attempt a fix lately, but I'll keep this issue updated

[lockhartja]

@mscheong01 was just reviewing and wanted to inquire -- does this blocked by an upstream dependency or simply a waiting for your available bandwidth to increase

[mscheong01]

Hi @lockhartja
First of all, sorry about the delay 😞
As for the cause of krotoDC being stuck to v3, both reasons that you listed are correct. I had 0 spare time lately due to my new internship over the summer and have not been able to make required change requests to the upstream protobuf project.
I've just opened a PR on protobuf repo: protocolbuffers/protobuf#17714 (which definitely shouldn't have taken this long 😭 )
Which will eliminated our current existing identified blocker to v4 and hopefully we'll be able to move up to v4 once this is merged & released.

[lockhartja]

Hi @mscheong01 sorry to interrupt just wanted check the current status of the upgrade....I completely understand if life has been life-ing...if I or the community can provide any assistance please let me know

[pambrose]

@mscheong01 Am I safe in assuming you have abandoned this project? If so, fine, no problem. But going dark is suboptimal.

[lockhartja]

@pambrose have you selected an alternative library? curious for recommendations....been reviewing suggestions from this post https://www.reddit.com/r/Kotlin/comments/1drl0zw/best_practices_for_kotlin_generated_classes_with/ -- and thought https://github.com/streem/pbandk looks promising

[pambrose]

Thanks for the links @lockhartja. In a perfect world, the kotlin/grpc team would add this functionality. pbandk definitley looks promising.

[lockhartja]

Wanted to add this cross-ref here for anyone looking for another alternative -- https://github.com/Kotlin/kotlinx-rpc seems like a good start to large organization supported implementation... @mscheong01 hope all that is well on your side of the world, thanks for the effort that you put into this library,

my project team has reverted back to the official grpc-kotlin implementation -- hopefully the Jetbrains implementation gains traction quickly...

cc: @pambrose

[mscheong01]

Sorry for the inconvenience 🥲. I've just been (and still am until mid December) too caught up to attend to this library - or any kind of opensource activity lately on gh.
The main blocker of V4 is that while KrotoDC respect explicitly written optional keywords on defaultly optional protoc fields, ProtobufV4 no longer does this - It would mean by going to V4, there would be a lot of unwanted breaking changes related to nullability.
Another problem that I had recently was a bug in WyriHaximus/github-action-get-previous-tag@v1 github actions library that stopped me from being able to publish to maven central. I haven't been able to attempt a release since, but I'll try again when I become available post December 15th.
I understand and fully support you decision to revert back to grpc-kotlin. This started off as a self-sufficient project that I created for my own development. However, I've currently set aside backend development for now, meaning that I no longer use this library myself.
I'm seeking to fix the deployment issue and upgrade dependencies that do not require breaking change, but for major patches like V4 upgrade, I'm afraid I can't guarantee when it will happen. If this stance of maintenance does not comply with your usecase, I recommend using grpc-kotlin.
If anyone seeks to take the above matter on their hands you're more then welcome - Freely send PRs. If they work, I'm open to inviting collaborators.