gRPC Kotlin missing active maintainers

[Ramiro Aparicio Gallardo]

I am raising the point again, after a couple of months have passed without any change.
The situation is worse now:
  * grpc-kotlin does not work with latest grpc-java version
  * the last release is still missing in maven.org even when it was released almost 6 months ago.

 * There is no support for editions 2023

It is fair and understandable that @lowasser as the single remaining maintainer does not have enough time to maintain the lib.

But Kotlin is an officially supported language in gRPC and and Google's endorsed language for Android development but the library has been in a bad situation for some time.

Maybe Jetbrains can come and help with the support or open it to the community but at the current state it is very likely that a fork will be needed sooner than later if there is no reaction from the gRPC team.

[Eric Anderson]

On Mon, Feb 3, 2025 at 12:52 PM 'Ramiro Aparicio Gallardo' via grpc.io <grp...@googlegroups.com> wrote:

The situation is worse now:
  * grpc-kotlin does not work with latest grpc-java version

I'm assuming you're referencing https://github.com/grpc/grpc-kotlin/issues/633 . That actually looks normal and I don't think you're blocked by any actions from grpc-kotlin. Add a dependency on io.grpc:grpc-stub:1.70.0 and you should be fine.

 * There is no support for editions 2023

I added a comment to https://github.com/grpc/grpc-kotlin/issues/625 to mention this is a problem for grpc-java as well. I'd hope it is as easy as setting a few fields that "edition 2023 is supported;" gRPC didn't really care about proto2 vs proto3.

 * the last release is still missing in maven.org even when it was released almost 6 months ago.

I think that's https://github.com/grpc/grpc-kotlin/issues/620

Maybe Jetbrains can come and help with the support or open it to the community but at the current state it is very likely that a fork will be needed sooner than later if there is no reaction from the gRPC team.

The release is definitely a problem and is a bit specialized because of permissions. But other than the release, part of the problem is (apparently; I don't think I have any extra insider knowledge) the amount of time being spent on it. If there's interest in a fork that would imply someone would need to spend time on it. Are you aware of people that should be considered to become maintainers of (or simply help) grpc-kotlin. I recognize that no merged PRs doesn't nurture maintainers, so there probably isn't "an obvious set of existing contributors."

[Ramiro Aparicio Gallardo]

Hi, thanks for taking a look, yeah, the main problem is that there is no active support for it, and everything gets derived from it, no replies for the tickets, and no new features added (there are like 3 different tickets requesting some way to add a global exception handler), dependencies are not up to date....
I am not aware of anyone considering creating a fork, but there are at least 4 competing alternatives for models Kotlin code generation and supporting libs because the official protobuf Kotlin models are not really stylistic or easy to use, I think one of them provides grpc support but it will not be that strange that given the lack of support, someone else would do it. We can try contacting them but  I am unsure if they would be willing to help maintain the "official" grpc-kotlin version. And as you said given the silence that reigns in the project it is difficult to gather a community that helps, if there was at least some maintenance maybe it would be enough to get some PRs for adding new features or fixing bugs.

[Louis Wasserman]

Our current planning suggests that I'll be able to give this considerable attention later in the year, but of course that isn't the same thing as sustained maintenance.

With that said, I would strongly prefer not to add any features to gRPC-Kotlin that are absent in gRPC-Java, to prevent future incompatibilities if gRPC-Java adds the same features in a different, incompatible form.  Most feature requests I have seen for gRPC-Kotlin fail that criterion.  (I'm not certain if the specific example of global exception handling is supported by gRPC-Java?)

[Eric Anderson]

On Tue, Feb 25, 2025 at 12:39 PM 'Louis Wasserman' via grpc.io <grp...@googlegroups.com> wrote:

With that said, I would strongly prefer not to add any features to gRPC-Kotlin that are absent in gRPC-Java, to prevent future incompatibilities if gRPC-Java adds the same features in a different, incompatible form.  Most feature requests I have seen for gRPC-Kotlin fail that criterion.  (I'm not certain if the specific example of global exception handling is supported by gRPC-Java?)

Looking at https://github.com/grpc/grpc-kotlin/issues/371 , it seems this is for service handlers throwing exceptions. It isn't all that clear why this is being requested. I see one case that talks about logging. You can make an interceptor that catches exceptions, which seems to have already been discussed. I don't recall offhand how Coroutines work with exceptions and in grpc-kotlin, so they may be contributing to the difficulty.

There could be some discussion for grpc-java to continue throwing exceptions up to the UncaughtExceptionHandler that is used in the Executor passed to serverBuilder.executor(). But right now our internal SerializingExecutor ends the RuntimeException propagation and logs directly. Errors are propagated up to UncaughtExceptionHandler. See issue 7725.