Protobuf: [Java] Generate hasXXX() methods for fields inside a oneof

[cbornet]

Currently in Java, one must compare the value of the oneof enum to know which field is contain in a oneof.
This is not very friendly to the end-user especially when you want to use oneof to provide nullability of the field. A generated hasXXX() method would be much more handy.
Also, I use mapstruct to map the generated protobuf classes to internal POJOs and it is capable of detecting if there is a hasFoo() method for a given foo field and using it in the mapping code it generates (see http://mapstruct.org/documentation/stable/reference/html/#source-presence-check). So such an enhancement would allow me to remove a lot of boilerplate code.

See also #1606 for the interest when dealing with nullable fields.

[cbornet]

Hi there, any comment ?

[acozzette]

@cbornet In the past we have talked about this a bit within the protobuf team but I think our conclusion has been that for proto3 we want to avoid hazzer methods for non-message oneof elements. The main reason is just to be consistent with primitive fields outside of oneofs. Another thing is that although oneofs can be useful for providing nullability, that is not really their intended use.

[cbornet]

Sorry but I don't get it. Primitive fields outside oneof are always present (they have a default value if not explicitely set) so I understand that a hazzer is not useful there. But in a oneof, the field can be there or not so a hazzer makes perfectly sense for this !
Nullability is just a particular case where the hazzer makes even more sense but it would also be useful for the general case.

[cbornet]

That's not nice... A lot of people want this...

[marcelbuesing]

I'd love to see this too. It might actually be the reason why we decide against Oneof in some cases although it is really convenient to use in powerful languages that support sum types (Swift, Scala, Haskell, Rust...) it becomes a hassle in e.g. Java and C#.

[jschultz410]

@acozzette "... I think our conclusion has been that for proto3 we want to avoid hazzer methods for non-message oneof elements."

Does this mean we shouldn't rely on the HasField() functionality in generated Python code for oneofs that contain scalar values?

https://developers.google.com/protocol-buffers/docs/reference/python-generated#oneof

If you are going to take away this kind of functionality in Python, then that will change how I deal with nullable fields.

Or is this just a case of Python getting to have a friendlier API than Java for some reason?

[acozzette]

I'm not really familiar with the Python API, but I think if it has HasField() methods for oneofs then it should be fine to use them. That seems inconsistent with the other languages, but it would be pretty unlikely that we would make a breaking change to try to remove those accessors.