apache/beam · error · IllegalArgumentException
Unknown implementation of Type
Error message
Unknown implementation of Type
What it means
ApiSurface.addExposedTypes(Type, Class) dispatches on the reflection Type implementation, handling ParameterizedType, TypeVariable, GenericArrayType, WildcardType and Class. A java.lang.reflect.Type instance of any other implementation (e.g. a custom or exotic Type produced by frameworks or bytecode manipulation) falls through to the else branch and throws IllegalArgumentException. It means the reflection type is of a kind this analyzer does not understand.
Source
Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/util/ApiSurface.java:581
*/
private void addExposedTypes(Type type, Class<?> cause) {
if (type instanceof TypeVariable) {
LOG.debug("Adding exposed types from {}, which is a type variable", type);
addExposedTypes((TypeVariable) type, cause);
} else if (type instanceof WildcardType) {
LOG.debug("Adding exposed types from {}, which is a wildcard type", type);
addExposedTypes((WildcardType) type, cause);
} else if (type instanceof GenericArrayType) {
LOG.debug("Adding exposed types from {}, which is a generic array type", type);
addExposedTypes((GenericArrayType) type, cause);
} else if (type instanceof ParameterizedType) {
LOG.debug("Adding exposed types from {}, which is a parameterized type", type);
addExposedTypes((ParameterizedType) type, cause);
} else if (type instanceof Class) {
LOG.debug("Adding exposed types from {}, which is a class", type);
addExposedTypes((Class) type, cause);
} else {
throw new IllegalArgumentException("Unknown implementation of Type");
}
}
/**
* Adds any types exposed to this set. These will come from the (possibly absent) bounds on the
* type variable.
*/
private void addExposedTypes(TypeVariable type, Class<?> cause) {
if (done(type)) {
return;
}
visit(type);
for (Type bound : type.getBounds()) {
LOG.debug("Adding exposed types from {}, which is a type bound on {}", bound, type);
addExposedTypes(bound, cause);
}
}
View on GitHub (pinned to 12126d8942)
Solutions
- Identify which class in the analyzed surface has the exotic Type (enable the LOG.debug output) and exclude it from the surface roots.
- Upgrade Beam — the dispatch set of handled Type kinds has been extended over time.
- Normalize the type first: if it comes from a framework, convert it to a standard Class/ParameterizedType before analysis.
Example fix
// before ApiSurface surface = ApiSurface.of(enhancedClasses, packages); // classes rewritten by an enhancement agent // after Set<Class<?>> plain = enhancedClasses.stream().map(Class::getSuperclass).collect(Collectors.toSet()); // analyze the original classes ApiSurface surface = ApiSurface.of(plain, packages);
Defensive patterns
Strategy: validation
Validate before calling
if (!(type instanceof Class) && !(type instanceof ParameterizedType) && !(type instanceof TypeVariable)
&& !(type instanceof GenericArrayType) && !(type instanceof WildcardType)) {
throw new IllegalArgumentException("unsupported reflection Type: " + type.getClass());
} Type guard
boolean isSupportedReflectType(java.lang.reflect.Type t) {
return t instanceof Class || t instanceof ParameterizedType || t instanceof TypeVariable
|| t instanceof GenericArrayType || t instanceof WildcardType;
} Prevention
- Avoid analyzing classes rewritten by bytecode-enhancement agents in API-surface checks.
- Normalize framework-provided Types to standard Class/ParameterizedType before analysis.
- Keep Beam SDK updated so newer reflection Type kinds are handled.
When it happens
Trigger: Analyzing an API surface that includes a field/method/generic signature whose resolved java.lang.reflect.Type is not one of Class, ParameterizedType, TypeVariable, GenericArrayType, or WildcardType — e.g. types synthesized by bytecode enhancement agents or custom Type implementations.
Common situations: Running API-surface checks on classes processed by code-generation/enhancement tools (AOP proxies, annotation processors) that inject custom Type implementations; unusual reflective generics in dependencies.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- error when invoking Coder factory method
- cannot register Coder : does not have an accessible method n
- cannot register Coder : method named 'of' with arguments of
- cannot register Coder : method named 'of' with arguments of
- cannot register Coder : method named 'of' with arguments of
AI-assisted analysis of apache/beam@12126d8942 (2026-09-13).
Data as JSON: /api/errors/92ad0543fa9b8ec4.
Report an issue: GitHub.