We should evaluate if using AutoValue is a good fit for us.
This will help to eliminate boilerplate code (though IDE's today typically help in the initial part and some
even in the maintenance part).
We should consider IDE support/behavior when the referred auto generated class is missing,
flexibility in copying set values (e.g. passed collection to immutable collection), replacing null with api-client Data.nullOf,..).
Also, it introduce the dependency of "@nullable" annotation and I think once users see that in the code they expect it in other places (so, we should go and change the code to use it consistently when applicable).
We should evaluate if using
AutoValueis a good fit for us.This will help to eliminate boilerplate code (though IDE's today typically help in the initial part and some
even in the maintenance part).
We should consider IDE support/behavior when the referred auto generated class is missing,
flexibility in copying set values (e.g. passed collection to immutable collection), replacing
nullwith api-clientData.nullOf,..).Also, it introduce the dependency of "@nullable" annotation and I think once users see that in the code they expect it in other places (so, we should go and change the code to use it consistently when applicable).