Re: GSoC 2026 Interest - Java and Python gRPC Integration (GSOC-318, #3272 #3273)

[Shawn Yang <ch...@apache.org>]

Hi Dimitris,

Thank you for your interest in the project and for reading through the
related issues and docs.

For GSoC, a pure Java project would not be acceptable. The project is
expected to include both Java and Python aspects, with clear
integration between them.

Regarding whether the generated *Grpc.java should handle Marshaller
instantiation entirely in generated code or rely on a small runtime
helper class, that is a design choice and should be discussed and
justified in your proposal.

Best,
Shawn Yang

On Tue, Mar 17, 2026 at 1:38 AM Dimitris Kall
<di...@gmail.com> wrote:
>
> Hi Chaokun,
>
> I am Dimitris, a senior IT student at The American College of Greece. I interned at Amazon last summer where I worked in Java and Go on backend microservices at production scale, and I have been writing Python for about 5 years now across personal-projects, research, and production contexts. I am very interested in the Java and Python gRPC integration project for GSoC 2026.
>
> I have read issues #3272 and #3273, the compiler guide and the grpc-service-design doc. The part I want to make sure I understand correctly before drafting a proposal is the Fory Marshaller for Java gRPC, is the expectation that the generated *Grpc.java handles Marshaller instantiation entirely through generated code, or will there be a small runtime helper class that the generated code depends on? I want to scope the Java deliverable accurately in my proposal.
>
> I am looking forward to hearing from you. Thank you for your time and consideration.
>
> Best regards,
> Dimitris
> GitHub | LinkedIn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@fory.apache.org
For additional commands, e-mail: dev-help@fory.apache.org

Re: GSoC 2026 Interest - Java and Python gRPC Integration (GSOC-318, #3272 #3273)

[Shawn Yang <sh...@gmail.com>]

1. The byte-for-byte assertion is not the target of this project. This
project focuses on grpc integration, not the serialization.
2. The GRPC integration is not coupled with fory mode, all xlang mode
should be supported. It's totally orthogonal

On Wed, Mar 18, 2026 at 9:17 PM Dimitris Kall
<di...@gmail.com> wrote:
>
> Hi Chaokun,
>
> Thank you for the clarification, both points are clear.
>
> Regarding the Marshaller, I wanted to confirm my understanding of the constraint that no new dependency can be introduced to the Fory serialization library. The generated *Grpc.java will be fully self-contained, with the Marshaller implemented entirely as generated code. For the Java Python integration, I restructured the proposal to place the bidirectional cross-language workflow at the center of the deliverable, instead of treating Java and Python as separate phases. The integration tests (Java server to/from Python client and Python server to/from Java client), along with a shared CI pipeline, are now positioned as the primary validation of the project.
>
> I have two questions where I would really appreciate your guidance before finalizing:
>
> The proposal uses semantic equality (field-by-field comparison) rather than byte-for-byte assertions in integration tests, since raw bytes may not be stable across languages when registration metadata differs. Do you consider semantic equality sufficient for primary assertions, or should byte-level stability be expected and tested in the initial unary case?
> For the Fory instance configuration in the generated createFory() factory, is there a preferred combination of modes (e.g., xlang mode, reference tracking, compatible mode) that the gRPC integration should target? Or should the factory expose these options and leave defaults to the caller?
>
> I have attached the revised proposal as a PDF. I would be very grateful for any feedback before the submission deadline, particularly on whether the proposed design and implementation for Java (#3272) and Python (#3273) gRPC code generation aligns with your expectations.
>
> Thank you again for your time and consideration.
>
> Best regards,
> Dimitris Kalligaridis
>
> On Tue, Mar 17, 2026 at 4:47 AM Shawn Yang <ch...@apache.org> wrote:
>>
>> Hi Dimitris,
>>
>> Thank you for your interest in the project and for reading through the
>> related issues and docs.
>>
>> For GSoC, a pure Java project would not be acceptable. The project is
>> expected to include both Java and Python aspects, with clear
>> integration between them.
>>
>> Regarding whether the generated *Grpc.java should handle Marshaller
>> instantiation entirely in generated code or rely on a small runtime
>> helper class, that is a design choice and should be discussed and
>> justified in your proposal.
>>
>> Best,
>> Shawn Yang
>>
>> On Tue, Mar 17, 2026 at 1:38 AM Dimitris Kall
>> <di...@gmail.com> wrote:
>> >
>> > Hi Chaokun,
>> >
>> > I am Dimitris, a senior IT student at The American College of Greece. I interned at Amazon last summer where I worked in Java and Go on backend microservices at production scale, and I have been writing Python for about 5 years now across personal-projects, research, and production contexts. I am very interested in the Java and Python gRPC integration project for GSoC 2026.
>> >
>> > I have read issues #3272 and #3273, the compiler guide and the grpc-service-design doc. The part I want to make sure I understand correctly before drafting a proposal is the Fory Marshaller for Java gRPC, is the expectation that the generated *Grpc.java handles Marshaller instantiation entirely through generated code, or will there be a small runtime helper class that the generated code depends on? I want to scope the Java deliverable accurately in my proposal.
>> >
>> > I am looking forward to hearing from you. Thank you for your time and consideration.
>> >
>> > Best regards,
>> > Dimitris
>> > GitHub | LinkedIn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@fory.apache.org
For additional commands, e-mail: dev-help@fory.apache.org