A couple of comments.

SingleThreadCachedTraversableResolver (or CachingTraversableResolverForSingleValidation as it is called in later versions of Validator is there to speed up TraversableResolver calls by caching calls to this class during a single validation call. How much this really improves the performance is a good question. This caching approach has been around since Validator 4 and it might be worth checking the actual benefit of this implementation.

Secondly, I was about to suggest that you can always plugin your own implementation of a TraversableResolver in case you want to bypass CachingTraversableResolverForSingleValidation, but I actually think we wrap any configured TraversableResolver into this caching one. There I think it would be beneficial to provide a configuration property which allows to bypass the caching.

Last but not least, regardless of any potential changes in Validator, I suggest to change your hashCode implementation to take into account potential null values. What if you are going to use an instance of your class in a Collection or Map or something similar. You will get exceptions in this case as well. Bean Validation occurs at given life cycle events, for example in the case of JPA during pre-persist. This means that until you call persist followed by a explicit flush or transaction commit, your entity will be un-validated. What if your entity is used in a one to many relation ship. Again you would get exceptions while still assembling your final object graph to persist. IMO hashCode must deal with potentially null values if it is possible that an instance can exist in a state where the value is null (even if from a business point of view the field is mandatory).