Java/C++/Python implementation inconsistent with proto json spec when marshaling empty proto in any proto

[lfolger]

See golang/protobuf#1620 for full context.

The protobuf Go implementation gerates a different output and expects a different input when converting a google.protobuf.Empty proto nested in and google.protobuf.Any proto to and from JSON compared to C++, Java and Python.

According to the discussion on the issue, the Go protobuf implementation seems to be consistent with the spec but inconsistent with other languages.

Copying the relevant parts from the other issue:

(not using quotes here to keep the original formatting):
start quote from dsnet:

The documentation for google.protobuf.Any.value says:

[The value field] must be a valid serialized protocol buffer of the above specified type.

Elsewhere, the documentation for google.protobuf.Any says:

If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field value which holds the custom JSON in addition to the @type field.

Then, the documentation for google.protobuf.Empty says:

The JSON representation for Empty is empty JSON object {}.

Thus, it seems that the current behavior is correct.

end quote

Is our interpretation/understanding of the documentation incorrect?
Would it be reasonable to adjust the documentation to reflect the behavior of the C++/Java/Python?
Alternatively, could the behavior of C++/Java be adjusted to align with the documentation?
I assume this is cost prohibitive and even aligning the Go implementation with C++ and Java might not be easy.

[honglooker]

Maybe worth updating docs, depending on your bandwidth, of course @Logofile

ref: #5390

[lfolger]

Given the inconsistencies and the fact that Java/C++ don't accept the currently documented formatting, would it be reasonable to make all parsers accept both formattings?

C++ seems to fail if I try to feed it {"@type":"type.googleapis.com/google.protobuf.Empty","value":{}}.

[puellanivis]

I think the only rational answer is that all parsers should accept both formats—for historical reasons. The only question is what should we align on the “canonical” preferred form.

[orloffv]

Hi,

Is there any plan to address the inconsistency with how empty proto messages are handled across different languages (C++, Java, Python)? Consistency here is important for reliable cross-language usage.

Thanks!

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

[puellanivis]

It seems like Java/C++/Python might be following the otherwise statement in the JSON mapping?

Otherwise, the value will be converted into a JSON object, and the "@type" field will be inserted to indicate the actual data type.

That is, it renders the Empty to an empty JSON object, and then inserts the "@type" field.