Steve Ebersole I know it's not the general case but I wanted to give a usecase where the current implementation isn't working very well.

To give some more context: I had two entities with different @Convert properties. Both classes didn't implement equals(..). One entity caused tons of updates without changing anything in DB (there was a @PreUpdate updating a timestamp to be exact), the other did not. It took me some time to spot this message in the log which finally helped me figure out what's going on.

But in order to return to the subject of this ticket: the log message for FallbackJavaTypeDescriptor isn't helpful right now and there is no way to get rid of it, even if it's working. I'd therefore recommend 2 simple improvements that don't require a full rewrite for 6.0:

1. FallbackJavaTypeDescriptor relies on hashCode() and equals(..) being implemented. This should be included in the log message.
2. The log message should only be issued at warning level if hashCode() and equals(..) aren't implemented: Object.class.equals(cls.getMethod("equals", Object.class).getDeclaringClass())
3. (bonus) use hints like java.lang.Cloneable or javax.annotation.concurrent.Immutable to guess the MutabilityPlan

Currently, if you google it you find people recommending making the class Serializable without mentioning the implications of using SerializableTypeDescriptor instead. I personally consider SerializableTypeDescriptor to be quite a nasty. Implementing hashCode() and equals(..) properly certainly is the preferred solution. The warning currently suggests otherwise.