quoted from protocolbuffers/protobuf#5450

Protobuf Java uses a null safe approach, at no point in protobuf-Java null is ever used.
Unset fields don't return null when you call its getters, they return a "default" value (empty, zero, EPOCH, etc...),
setters will always throw NPE if you try to pass them null.

I think it's a safer practice to always return an object instead of null from a mapper method:

• map domain to proto => returning an object is clearly the right thing to do: because albeit it is completely acceptable for the fields of the domain object to be null at the application level, but this should not result in NPE when sending those objects over the network using protobuf. The non-null policy enforced by protobuf should be respected by mappers (hand written or generated), but it is not an application concern and it should not leak outside the application's mapper package.
• map proto to domain => the best course of action is to pass the value returned by the proto verbatim to the domain object. IMHO, If a generated mapper takes on him to convert protobuf default values to null it clearly steps on the application prerogatives. The application is the only one knowing if and when to convert "default" values to null in a post-mapping sanitization step using all the knowledge it have of the data. Applying a default-to-null policy is an application concern, not a mapstruct concern.
  Beside the risk is that the end result would be different between an object mapped via a mapstruct generated mapper and the same type of object mapped by a similar hand written mapper (breaking the least-astonishment-principle).

Regards.