[proposal] Move gRPC-zero to Quarkus core

[andreaTP]

Description

With this issue, I’d like to propose continuing the effort started with grpc-zero, and replacing the current default implementation of GrpcCodeGen.

As a quick recap, grpc-zero works by compiling official protobuf sources(C++) to Wasm, and then from Wasm to Java bytecode using Chicory. This guarantees a 1:1 behavioral match without requiring architecture or OS specific binaries.

Key advantages:

• No native dependencies (for example, this section becomes obsolete)
• A small, self-contained build-time dependency

Implementation ideas

Possible approaches:

1. Keep the current implementation available behind a legacy flag

• Pros:
  • Minimal breaking changes
  • Straightforward backward compatibility for users
• Cons:
  • Both implementations remain on the classpath, so we cannot remove the large transitive dependencies required by the current implementation significantly reducing the benefits of the new approach.

2. Move the current implementation to a separate -legacy module

• Pros:
  • New users benefit from the new setup by default
• Cons:
  • Double maintenance
  • Potentially more complex Maven setup to run integration tests across both implementations

3. Move the current implementation to a Quarkiverse repository and fully replace it with grpc-zero

• Pros:
  • Reduced maintenance
  • Clear forward direction
• Cons:
  • The most breaking option for users who rely on the current implementation. Restoring the previous behavior would require explicitly adding a different Maven dependency.

Additional considerations

grpc-zero currently passes 100% of the gRPC-related integration tests in this repository, with zero changes required aside from swapping in the new codegen. I’ve received a few reports of successful migrations without issues or additional modifications needed.

---

I’d like to gather feedback on this proposal. My preferred path forward is option 3, with the first release targeted for next year to ensure I have maximum availability to address any new issues and assist users during the transition.

cc. @cescoffier @Sanne @jponge @alesj

[quarkus-bot[bot]]

/cc @alesj (grpc), @cescoffier (grpc)

[cescoffier]

Thanks for starting this discussion.

I agree that option 3 is the cleanest and the most future-oriented direction. However, we need to be careful here: protoc is notoriously tricky, with odd corner cases and unexpected behaviors. We also need to align with the Vert.x team, because Vert.x 5 brings important features we want in Quarkus 4 (transcoding, gRPC-Web), and both rely on additional protoc plugins.

Given this, I think that option 2 is the right next step. Keeping both modules in the repository, making grpc-zero the default, and providing clear guidance on how to use protoc gives us room to validate the approach without fully removing the existing implementation. If we are satisfied with grpc-zero after a transition period (typically until Quarkus 4), we can consider moving the protoc-based codegen out of core.

Concretely, I see the next steps as: 1. Ensure that all our examples and integration tests pass with grpc-zero (@alesj can help here). 2. Review outstanding protoc-related issues reported by users (https://github.com/quarkusio/quarkus/issues?q=is%3Aissue%20state%3Aopen%20protoc) and check whether some are now resolved. The Kotlin-related ones are particularly interesting. 3. Bring the Vert.x team into the discussion to align on upcoming requirements (transcoding, gRPC-Web, additional plugins).

[jponge]

If we go with option 2, then I would refrain from naming the existing modules as -legacy. I'd keep them as-is, and have that new (default) option being grpc-zero.

[andreaTP]

Thanks for the feedback, I'm ok moving on with Option 2, and yes, we can keep the current naming and just change the default, agreed 👍

next steps:

1. the integration tests should be already covered, do you have an automated way to verify examples?
2. I took a brief look at the open issues:
   • pre-existing bugs/new-features/enhancements: unless explicitly requested, I'd refrain from moving forward on those to keep the situation as stable as possible to start with
   • V3/v4 discussions: protobuf4j already supports both, seems like the switch is blocked by other factors (I'd welcome a careful review of the transitive dependencies though)
3. happy to bring the discussion forward with the VertX team, I started speaking with @vietj but feel free to send my way anyone relevant

[alesj]

Yeah, 3) would be ideal, but probably too risky to start with.

So we should go with 2), but make sure we run all tests with both impls. Can this be done with multiple executions in maven-surefire-plugin or do we have to have multiple profiles? I guess we can play with this and see how it goes ...

[Sanne]

If we go with option 2, then I would refrain from naming the existing modules as -legacy. I'd keep them as-is, and have that new (default) option being grpc-zero

+1 to keep such a decision separate