Protobuf: Java lite does not generate hasField methods and does not serialize zero values

[mxk]

This was a big design issue in nano and I was under the impression that it was fixed in lite, but apparently not. Basic types do not have corresponding hasField() methods and zero values are not encoded in the serialized messages. Nano compiler had reftypes option. Is there an equivalent for lite?

[xfxyjwf]

You are probably using proto3 syntax and has-bits has been explicitly removed from proto3.

If you declare your .proto files with 'syntax = "proto2";', you should be able to get the hasField() methods back.

[mxk]

I am using proto3 and hasField() methods are still generated for submessages, but not for scalar fields. It makes no sense to generate them for one field type, but not another. Scalar fields need to be represented with autoboxed types where null means missing for both encoding and decoding. That's the only sensible design. There must be a way to transmit the value false or 0 and have the receiver distinguish that from a missing field.

[snapsam]

You might find this relevant: https://github.com/google/protobuf/issues/249

[xfxyjwf]

@mxk

We have to be able to tell whether a sub-message is set or not to avoid infinite recursion:

message Foo {
  Foo child = 1;
}

Part of the reason to drop has-bits is for performance. Tracking it using separate bits or using autoboxed type as you suggested does have its own cost. We have to make a trade-off here and it's our believe that removing it simplifies the language and helps improve performance in certain languages. We already released proto3 for a while and it's unlikely that this design choice will be changed.

Note that we still fully support proto2. If you like the semantics of proto2 better, you can continue to use it. Protobuf itself uses proto2 also (see the descriptor.proto) and that's not going to change any time soon.

[mxk]

Fair enough. Until I can redesign my messages, I've switched to square/wire to interact with nanopb on the other side. Both provide field presence information. Personally, I think this change is more likely to result in ugly designs with many single-field messages or bools represented by enums to have three separate values for unset, true, and false.