Hi Chris Cranford,

Thanks a lot for your reply!

Please, let's forget about the old Criteria API, since this is not an issue directly pertaining to the Criteria API itself, old or new. I know I was the one to come up with the Criteria API example, but this was a mistake. I apologize for that. The Criteria API is irrelevant, the problem is entirely in the AttributeConverter code. This problem can be completely solved by a simple change in the AttributeConverterSqlTypeDescriptorAdapter file, which is NOT in any way related to any Criteria/JPA API.

Let's, instead, think in terms of what converters should be and should not be doing.

This problem prevents many kinds of comparisons between converted classes that map to not only String, but also to numbers, or dates. For example, numbers are ordered, and objects of type `Year` that convert to numbers must be comparable to other `Year`s and also to numbers, in the database, so that I can query `year1> year2`, but also `year1 > 2017`.

So, what should converters do, in the Java to database leg? Two things:

A) They should convert JavaType input into SqlType output.
B) But if the input is already of SqlType they must do nothing.

You are currently doing only (A) by assuming input always comes as JavaType. This is a false and unnecessary assumption, and makes the current code brittle.

What I suggest is to make that code more robust by simply changing that line 77 as I described, and then run your tests:

Class javaClass = intermediateJavaTypeDescriptor.getJavaTypeClass();
Class valueClass = value.getClass();
if (javaClass.isAssignableTo(valueClass()) {  
    convertedValue = converter.convertToDatabaseColumn(value); 
    }
else {
   convertedValue = value; 
}

The above code change should be enough. If tests pass, problem solved. And they should pass because by its very nature this fix should have no collateral effects.