What causes "No support for parsing UserType values from String: {}" in hibernate/hibernate-orm?

Identify and remove the operation that needs string parsing for the @CompositeType attribute (restructure the query/lookup to avoid string round-trips).

hibernate/hibernate-orm · error · UnsupportedOperationException

No support for parsing UserType values from String: {}

Error message

No support for parsing UserType values from String: {}

What it means

CompositeUserTypeJavaTypeWrapper adapts a CompositeUserType to Hibernate's JavaType SPI; its fromString (CompositeUserTypeJavaTypeWrapper.java:96-99) throws unconditionally because the CompositeUserType contract has no hook for parsing a value from its string form. The error surfaces whenever an operation requires materializing an @CompositeType attribute from a String representation, which composite user types simply cannot support.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/type/internal/CompositeUserTypeJavaTypeWrapper.java:99

	@Override
	public Comparator<J> getComparator() {
		return comparator;
	}

	@Override
	public int extractHashCode(J value) {
		return userType.hashCode(value );
	}

	@Override
	public boolean areEqual(J one, J another) {
		return userType.equals( one, another );
	}

	@Override
	public J fromString(CharSequence string) {
		throw new UnsupportedOperationException( "No support for parsing UserType values from String: " + userType );
	}

	@Override
	public <X> X unwrap(J value, Class<X> type, WrapperOptions options) {
		assert value == null || userType.returnedClass().isInstance( value );
		return type.cast( value );
	}

	@Override
	public <X> J wrap(X value, WrapperOptions options) {
//		assert value == null || userType.returnedClass().isInstance( value );
		//noinspection unchecked
		return (J) value;
	}

	@Override
	public Class<J> getJavaTypeClass() {
		return userType.returnedClass();

View on GitHub (pinned to fad1729dce)

Solutions

Identify and remove the operation that needs string parsing for the @CompositeType attribute (restructure the query/lookup to avoid string round-trips).
If string parsing is a hard requirement, replace the CompositeUserType with a plain UserType that implements EnhancedUserType, or with an AttributeConverter on a basic column type.
Map the structure as a regular @Embeddable instead of a CompositeUserType - embeddables support component-based construction.
Catch UnsupportedOperationException at the call site and degrade gracefully if the operation is optional.

Example fix

// before - composite user type cannot be built from a String
public class AddressType implements CompositeUserType<Address> { ... }
// any Hibernate path calling javaType.fromString(...) -> UnsupportedOperationException

// after - use an AttributeConverter that parses from the stored string
@Converter
public class AddressConverter implements AttributeConverter<Address, String> {
    @Override public String convertToDatabaseColumn(Address a) { return a == null ? null : a.toLine(); }
    @Override public Address convertToEntityAttribute(String s) { return s == null ? null : Address.parse(s); }
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Before relying on string round-trips of a @CompositeType attribute,
// verify the capability exists on its JavaType:
JavaType<?> jt = sessionFactory.getTypeConfiguration()
        .getJavaTypeRegistry()
        .resolveDescriptor( MyCompositeType.returnedClass() );
if ( !StringRepresentableType.class.isInstance( jt ) ) {
    // avoid operations that need fromString() for this attribute
}

Try / catch

try {
    // operation that may need to materialize the composite value from a String
} catch ( UnsupportedOperationException e ) {
    if ( e.getMessage() != null && e.getMessage().startsWith( "No support for parsing UserType values" ) ) {
        // fall back to a query/lookup strategy that does not require string parsing
    } else throw e;
}

Prevention

Do not use @CompositeType attributes where string round-trips (string ids, string-based extraction) are needed - use an AttributeConverter or plain UserType instead.
Document per attribute type whether string parsing is supported.
Add integration tests covering every lookup style used with custom types.

When it happens

Trigger: Using an attribute mapped with @CompositeType(MyCompositeType.class) in a context where Hibernate asks the JavaType to parse a String (string-based result extraction, string-representable id/natural-id lookups, APIs that need JavaType.fromString); any custom code that calls javaType.fromString on the adapted descriptor.

Common situations: Switching an embeddable to a CompositeUserType and then needing string round-trips the embeddable used to provide; integrations or query features that assume every JavaType can parse its toString output.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/0b04bce5bc183af6. Report an issue: GitHub.