Question about json_name and protoc

[Zellyn]

Hey folks,

We're trying to update the version of protoc we use for compiling our Go protobufs. It appears that at some point between 3.0.0 and 3.6.0, protoc started populating the `json_name` field option for every field, whether the option was specified or not. Is that expected? If so, could anyone help me track down the commit that did it?

Thanks,

Zellyn

[Zellyn]

A quick followup: a reason that including a json name for every field in the descriptor is bad: it makes it impossible to tell whether an explicit json_name was specified or not. So it would be impossible to give jsonpb a mode (which it needs, imho) where it uses the protobuf field names as-is, unless an explicit json_name was specified.

Or am I understanding it wrong?

Zellyn

[Josh Humphries]

Hey, Zellyn,

I don't think it's possible for protoc-gen-go to do what you're asking. IIRC, protoc itself always populates this field in the field descriptor. So I don't think a plugin can actually make this distinction -- at least not without a change to protoc. And the downside to a change to protoc is that it would require all code-gen plugins (and/or runtime libraries that implement the JSON encoding) to have redundant logic for computing the canonical JSON name from the proto name.

----
Josh Humphries
jh...@bluegosling.com

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Zellyn]

Yeah, it's precisely the fact that protoc populates that field regardless of whether it was specified that I consider bad. https://github.com/protocolbuffers/protobuf/issues/5587

I'm probably way too late to get it fixed, though: it looks like 3.1.0 introduced that behavior :-(

Zellyn

[Josh Humphries]

On Wed, Jan 16, 2019 at 12:56 PM Zellyn <zel...@gmail.com> wrote:

Yeah, it's precisely the fact that protoc populates that field regardless of whether it was specified that I consider bad. https://github.com/protocolbuffers/protobuf/issues/5587

Doh, I apparently misread your original email, thinking you were talking about the generated Go code only.

FWIW, I think most decoders (for the runtimes that support JSON encoding) support either: they first look for a matching name per JSON name, and, if no field is found, they fall back to looking for a matching proto name. Perhaps that may help if you are trying to, for eaxmple, bridge a pre-3.0 custom JSON encoding with proto3 canonical JSON encoding (just kind of guessing at your possible reason for needing this distinction). If that is the motivation, you might also watch out for the custom JSON encoding for well-known types and how one-ofs are handled (e.g. one-of names never appear in JSON; their constituents are flattened into the enclosing message).