spring-projects/spring-framework · error · UnsupportedOperationException

TypeDescriptor resolution not supported

Error message

TypeDescriptor resolution not supported

What it means

UnsupportedOperationException thrown by the default method TypeConverter.convertIfNecessary(value, requiredType, TypeDescriptor). The interface ships this overload as a default that deliberately fails; real implementations (TypeConverterSupport, BeanWrapperImpl, SimpleTypeConverter) override it to delegate to a TypeConverterDelegate. Hitting it means a custom/minimal TypeConverter implementation did not override the TypeDescriptor-aware overload.

Solutions

  1. Extend TypeConverterSupport (or BeanWrapperImpl / SimpleTypeConverter) instead of implementing TypeConverter from scratch so you inherit the delegation.
  2. If you must implement the interface, override convertIfNecessary(value, requiredType, TypeDescriptor) to delegate to your own TypeConverterDelegate.
  3. Update the calling code to use an overload your converter supports, though this is rarely the right fix.

Example fix

// before
public class MyConverter implements TypeConverter {
    public <T> T convertIfNecessary(Object v, Class<T> t, Field f) { /* ... */ }
}

// after — extend support class instead of re-implementing
public class MyConverter extends TypeConverterSupport {
    // inherits TypeDescriptor delegation; supply a TypeConverterDelegate if needed
}
Defensive patterns

Strategy: type-guard

Validate before calling

// Ensure your converter supports the TypeDescriptor overload before it is called
if (!(converter instanceof TypeConverterSupport)) {
    throw new IllegalStateException("converter must support TypeDescriptor conversion");
}

Type guard

static boolean supportsTypeDescriptor(TypeConverter c) {
    return c instanceof TypeConverterSupport || c instanceof BeanWrapper;
}

Prevention

When it happens

Trigger: Implementing TypeConverter directly and only overriding the (value, requiredType) or (value, requiredType, Field) overloads, then code calling the three-argument TypeDescriptor variant (used by DataBinder, SpEL, and @ConfigurationProperty binding since 5.1.4).

Common situations: Custom TypeConverter stubs in tests; lightweight frameworks that predate Spring 5.1 and were never updated for the TypeDescriptor overload; mocking TypeConverter without stubbing all overloads.

Related errors


AI-assisted analysis of spring-projects/spring-framework@69bf83ad71 (2026-08-09). Data as JSON: /api/errors/c2904f9bf25767f1. Report an issue: GitHub.

Appendix: source

Thrown at spring-beans/src/main/java/org/springframework/beans/TypeConverter.java:114

	 * Convert the value to the required type (if necessary from a String).
	 * <p>Conversions from String to any type will typically use the {@code setAsText}
	 * method of the PropertyEditor class, or a Spring Converter in a ConversionService.
	 * @param value the value to convert
	 * @param requiredType the type we must convert to
	 * (or {@code null} if not known, for example in case of a collection element)
	 * @param typeDescriptor the type descriptor to use (may be {@code null}))
	 * @return the new value, possibly the result of type conversion
	 * @throws TypeMismatchException if type conversion failed
	 * @since 5.1.4
	 * @see java.beans.PropertyEditor#setAsText(String)
	 * @see java.beans.PropertyEditor#getValue()
	 * @see org.springframework.core.convert.ConversionService
	 * @see org.springframework.core.convert.converter.Converter
	 */
	default <T> @Nullable T convertIfNecessary(@Nullable Object value, @Nullable Class<T> requiredType,
			@Nullable TypeDescriptor typeDescriptor) throws TypeMismatchException {

		throw new UnsupportedOperationException("TypeDescriptor resolution not supported");
	}

}

View on GitHub (pinned to 69bf83ad71)