apache/iceberg · error · RuntimeException
Cannot find method: ${name}
Error message
Cannot find method: ${name} What it means
DynMethods.Buildable.build() throws a RuntimeException when reflective lookup found no implementation for the requested method name across the tried classes/packages. It is used for optional third-party integrations where Iceberg falls back to plain reflection because a compile-time dependency does not exist. The runtime exception signals the target class/method is absent from the runtime classpath or has an incompatible signature.
Source
Thrown at common/src/main/java/org/apache/iceberg/common/DynMethods.java:468
* @see java.lang.Class#getMethod(String, Class[])
*/
public Builder hiddenImpl(Class<?> targetClass, Class<?>... argClasses) {
hiddenImpl(targetClass, name, argClasses);
return this;
}
/**
* Returns the first valid implementation as a UnboundMethod or throws a RuntimeError if there
* is none.
*
* @return a {@link UnboundMethod} with a valid implementation
* @throws RuntimeException if no implementation was found
*/
public UnboundMethod build() {
if (method != null) {
return method;
} else {
throw new RuntimeException("Cannot find method: " + name);
}
}
/**
* Returns the first valid implementation as a BoundMethod or throws a RuntimeError if there is
* none.
*
* @param receiver an Object to receive the method invocation
* @return a {@link BoundMethod} with a valid implementation and receiver
* @throws IllegalStateException if the method is static
* @throws IllegalArgumentException if the receiver's class is incompatible
* @throws RuntimeException if no implementation was found
*/
public BoundMethod build(Object receiver) {
return build().bind(receiver);
}
/**View on GitHub (pinned to 86d9c8fc54)
Solutions
- Check the classpath contains the exact dependency version whose method signature the DynMethods lookup targets (mvn dependency:tree / jar tf)
- Verify the method name and parameter types passed to the DynMethods builder match the target class
- Print the failing lookup target from the message and inspect the jar on the runtime classpath, not the compile-time one
- Switch to buildChecked() and handle NoSuchMethodException to degrade gracefully instead of failing
- Exclude/relocate conflicting shaded copies of the dependency
Example fix
// before
UnboundMethod m = DynMethods.builder("putToByteBuffer").impl(UnsafeUtil.class, ByteBuffer.class, long.class, byte[].class).build();
// after
UnboundMethod m;
try {
m = DynMethods.builder("putToByteBuffer").impl(UnsafeUtil.class, ByteBuffer.class, long.class, byte[].class).buildChecked();
} catch (NoSuchMethodException e) {
m = null; // fall back to non-reflective path
} Defensive patterns
Strategy: try-catch
Validate before calling
// Precheck reflective availability
try {
Class.forName("com.example.ThirdParty").getMethod("target", ParamType.class);
} catch (ClassNotFoundException | NoSuchMethodException e) {
LOG.warn("Reflective target unavailable: {}", e.getMessage());
} Type guard
boolean hasImpl(DynMethods.UnboundMethod.Builder b) { try { b.buildChecked(); return true; } catch (NoSuchMethodException e) { return false; } } Try / catch
try { UnboundMethod m = builder.build(); } catch (RuntimeException e) { /* fall back to non-reflective path */ } Prevention
- Pin the exact dependency version the reflective lookup targets
- Use buildChecked() for optional integrations
- Provide multiple impl(...) candidates for different dependency versions
- Watch for shaded/relocated classes in fat jars
When it happens
Trigger: Calling UnboundMethod builder .buildImpl(...)/.build(...) when no ctor/impl matched: class not present, method renamed in the dependency version on the classpath, or loader cannot see the class.
Common situations: Deploying Iceberg against a different version of a dependency (e.g. Hadoop, AWS SDK, Parquet) than the one the reflective lookup expects; fat-jar shading that strips classes; classloader isolation in app servers or Spark/Flink containers.
Understand the failure class
Background: "not installed", "pip install", "required for": how missing-dependency errors surface across open-source libraries — this error's family across 34 libraries.
Related errors
- Cannot load class %s, it does not exist in the classpath
- Cannot load class %s, it does not exist in the classpath
- Cannot find class; alternatives: ${classNames}
- Cannot initialize Catalog implementation %s: %s
- Cannot initialize FileIO implementation %s: %s
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/f017bd9fd08e57aa.
Report an issue: GitHub.