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

  1. Check the classpath contains the exact dependency version whose method signature the DynMethods lookup targets (mvn dependency:tree / jar tf)
  2. Verify the method name and parameter types passed to the DynMethods builder match the target class
  3. Print the failing lookup target from the message and inspect the jar on the runtime classpath, not the compile-time one
  4. Switch to buildChecked() and handle NoSuchMethodException to degrade gracefully instead of failing
  5. 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

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


AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/f017bd9fd08e57aa. Report an issue: GitHub.