Rafael Tedin Alvarez thanks for sharing these insights!

I see where you are coming from and feel it's a rather unfortunate corner case you are hitting here. I also believe that hashCode() implementations should be safe towards null-valued properties if those can actual occur (which they do in your case, although only in the special case of deserialization).

I think your case would ideally be solved by having Jackson use the builder during deserialization, enforcing the null check during construction of the object (no idea though whether Jackson is flexible enough to achieve that). Then the invariant would be enforced, and HV would never see such illegally constructed object.

That being said, I'm wondering whether we couldn't change the code in CachingTraversableResolverForSingleValidation to use System#identityHashCode() instead of invoking the object's hashCode() method. Actually, the identity of the object and the traversed property should be enough as the identity for the cache key type TraversableHolder. Hardy Ferentschik, WDYT?