In our case, we cannot change the code of hashCode(). We use an annotation processor to generate an immutable class and its builder. The builder ensures that all mandatory fields are non-null when an instance of the class is built. Therefore the generated hashCode() does not have to check for null fields. We cannot change the code that is generated. I actually consider it a feature that the code is generated as it is since it assumes a class invariant that must hold. Changing the hashCode() to handle null could potentially mask errors.

Now the problem comes when we deserialize an instance of that class from JSON effectively bypassing the builder. There is where we want to perform the validation. But if the validation process itself assumes that an instance has to valid, we are in a catch-22 that we cannot escape from. As @oleg, I also consider that the current behavior is conceptually wrong.