Reference HHH-9615[1]. The specific request here is to support @Lob together with an AttributeConverter. But other combinations apply as well. So I want to address the more generic case, but let's talk in terms of this specific case. Ultimately the problem is in SimpleValueBinder and the fact that it keeps just one representation of the "determined Type" (`explicitType`) and that it furthermore treats that value as if it were explicitly requested. When it is determining the Type to use and it sees @Lob, @Natioanlized, etc it assumes that that implicitly defines the Type to use, but then treats that determination as if it were explicit. Late we have a check to make sure that the user did not mix applying an AttributeConverter and an (really) explicit Type definition on an attribute, because that would be a unresolvable situation. Really, instead I think this should work quite differently. To me, I would not say that @Lob equates to an explicit Type request. Instead I would say that it is a hint as to the Type, and actually even more limited I would say it is a hint as to just the JDBC type. Really @Lob has no bearing on the Java model type. So what I'd propose instead (keeping changes as minimal as possible until we rewrite the annotation binding code) would be to defer this decision for @Lob into SimpleValue itself. I think the least disruptive way would be a method on SimpleValue similar in intent to SimpleValue#makeNationalized. So add a SimpleValue#makeLob that we'd call from SimpleValueBinder when @Lob was present. We would then incorporate handling LOB interpretation into SimpleValue#setTypeUsingReflection and SimpleValue#buildAttributeConverterTypeAdapter. Does this sound reasonable to everyone? Emmanuel, you wrote and designed SimpleValueBinder; does that make sense from the perspective of the overall design/intent of SimpleValueBinder? [1] https://hibernate.atlassian.net/browse/HHH-9615