We have a custom type that takes a java.util.Date on the nullSafeSet and returns a java.sql.Timestamp from the nullSafeGet. This allows us some flexibility in our entities to use java.util.Date for our fields instead of java.sql.Timestamp if the consumer so desires.

We have recently encountered some problems with this custom type when trying to set the parameter value as a java.util.Date when using Filters. Because the nullSafeGet returnes java.sql.Timestamp, we have the getReturnedClass() return java.sql.Timestamp. The following code in FilterImpl will not work with that setup.



We end up with which isn't true.
I'm wondering though if this check might be backwards? Since filters are used to populate parameters in queries it seems it would be more like a nullSafeSet as opposed to the nullSafeGet. The nullSafeSet can afford to be somewhat lenient in the type that is being accepted and allow super types to be accepted. Whereas the nullSafeGet would need to be more specific so that the lowest level of the inheritance hierarchy is specified so that it can be used on the entity if so desired.

I realize I'm looking at this from the perspective of a very targeted use case and there is ?possibly? some reason that the code needs to work this way. I just wanted to start the discussion in case this code would happen to be incorrect or unneeded and others ran into the same situation which we have run into.