Example for use with protocol buffers about j2cl HOT 9 OPEN

WIP but https://github.com/google/j2cl-proto

from j2cl.

Default Java protobuf implementation would not work with J2CL as it relies on reflection.

We have a particular implementation of J2CL that generates the same API but makes it JavaScript friendly. We are looking into open-sourcing it but cannot give you a definite time line.

from j2cl.

@gkdn thank you for your response on this. is there any update? it is becoming a blocker for us

from j2cl.

@gkdn thank you for sharing, this looks awesome.

from j2cl.

j2cl-proto should be working fine for a while now. That would be great if somebody could put some samples there but for the purposes of this bug, I think we are don.

from j2cl.

There was a mistake on the release. Re-opening this.

from j2cl.

@gkdn i have a few questions, when you have some time to answer them (i know this is still under development).

1. we're already using protobuf JS and grpc-web in our frontend dependency mix - how might we pass objects between J2CL and other Closure-enabled code in JS?

2. what about gRPC on the J2CL side? assuming the answer to q#1 is complex, and we choose to keep all of our code in J2CL land (avoiding the need to bridge back and forth for immutable JS proto records), how would we dispatch to gRPC and back to produce those objects in J2CL?

from j2cl.

in any case, i'm excited to use this more, and i've integrated J2CL into Elide (the framework) and our own internal apps. but that's what's holding me up from using it in full, because our object model heavily uses protobuf, and so without those objects, J2CL is relegated to sharing constants between the frontend and backend, when it can do so much more.

from j2cl.

we're already using protobuf JS and grpc-web in our frontend dependency mix - how might we pass objects between J2CL and other Closure-enabled code in JS?

This is why we introduced immutable js proto under the J2CL proto repository. It provides seamless integration with closure. And they were "suppose" to be easy to convert to mutable protobuf JS.
I'm saying "suppose to" because we currently don't support binary wire format. We support something called JSPB which is the google's internal format. Without binary you cannot replace your existing protobuf JS usages in open-source nor easily convert them. So you would need to do copy manually or via code generation.

On the bright side, the discussions of supporting binary format in immutable protobuf as well as converging to a single js protobuf implementation is still ongoing.

what about gRPC on the J2CL side?

I don't have gRPC experience but I assume it would be using the standard proto serialization (i.e. binary format). If you would like to avoid bridging via immmutable js proto then you would need to maintain your own @JsType(isNative=true) Java model objects that maps to Closure types.
You can also experiment with auto generating them via protoc plugin (similar to J2CL protos).

from j2cl.