could not find method %s from class %s with signature %s

Error message

could not find method %s from class %s with signature %s

What it means

jni_helper.c resolves and caches JNI method IDs via methodIdFromClass using GetMethodID/GetStaticMethodID. When the JVM cannot find the named method with that exact signature on the class, libhdfs prints this message and propagates the pending JVM exception (typically NoSuchMethodError). In practice this means the native library and the Hadoop jars on CLASSPATH come from different versions, or the classes were relocated by shading.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/jni_helper.c:310

jthrowable methodIdFromClass(jclass cls, const char *className,
        const char *methName, const char *methSignature, MethType methType,
        JNIEnv *env, jmethodID *out)
{
    jthrowable jthr;
    jmethodID mid = 0;

    jthr = validateMethodType(env, methType);
    if (jthr)
        return jthr;
    if (methType == STATIC) {
        mid = (*env)->GetStaticMethodID(env, cls, methName, methSignature);
    }
    else if (methType == INSTANCE) {
        mid = (*env)->GetMethodID(env, cls, methName, methSignature);
    }
    if (mid == NULL) {
        fprintf(stderr, "could not find method %s from class %s with "
            "signature %s\n", methName, className, methSignature);
        return getPendingExceptionAndClear(env);
    }
    *out = mid;
    return NULL;
}

jthrowable classNameOfObject(jobject jobj, JNIEnv *env, char **name)
{
    jthrowable jthr;
    jclass cls, clsClass = NULL;
    jmethodID mid;
    jstring str = NULL;
    const char *cstr = NULL;
    char *newstr;

    cls = (*env)->GetObjectClass(env, jobj);
    if (cls == NULL) {

View on GitHub (pinned to 2add963021)

Solutions

Set CLASSPATH from the same installation that provides libhdfs.so: eval "$(hadoop classpath --glob)"
Ensure exactly one version of hadoop-common and hadoop-hdfs client jars is reachable on the CLASSPATH
Replace or rebuild libhdfs.so so its version matches the jars
Restart the process after fixing the classpath, since cached class/method state lives as long as the JVM

Example fix

# before
export CLASSPATH=/opt/old-hadoop/share/hadoop/common/*:/opt/old-hadoop/share/hadoop/hdfs/*

# after (single matching installation)
export HADOOP_HOME=/opt/hadoop-3.3.6
export LD_LIBRARY_PATH=$HADOOP_HOME/lib/native
export CLASSPATH="`$HADOOP_HOME/bin/hadoop classpath --glob`"

Defensive patterns

Strategy: validation

Validate before calling

/* fail fast at startup: environment must be coherent before any libhdfs call */
static int check_hadoop_env(void) {
    const char *cp = getenv("CLASSPATH");
    const char *lp = getenv("LD_LIBRARY_PATH");
    if (!cp || !*cp) return -1;          /* no classpath */
    if (!lp || !strstr(lp, "native")) return -2;  /* libhdfs.so dir missing */
    return 0;
}

/* plus smoke-test: */
/* hdfsBuilderConnect + hdfsExists(fs, "/") — failure here means a JNI/classpath mismatch
   caught at deploy time, not mid-job */

Try / catch

hdfsFS fs = hdfsConnect("hdfs://nn:8020", NULL);
if (fs == NULL) {
    /* EINTERNAL from getJNIEnv: inspect stderr for the methodIdFromClass message and
       fix CLASSPATH/libhdfs version alignment; do not retry with the same env */
}

Prevention

Generate CLASSPATH with `hadoop classpath --glob` from the installation that provides libhdfs.so
Keep LD_LIBRARY_PATH (libhdfs.so, libjvm.so) and CLASSPATH pinned in one versioned env script
Smoke-test one hdfsConnect/hdfsExists at startup so a JNI mismatch fails the deployment, not production traffic

When it happens

Trigger: libhdfs.so built against Hadoop X while CLASSPATH contains hadoop-common/hadoop-hdfs jars from Hadoop Y where the method was added, removed, renamed, or given a different signature; two versions of a jar on the CLASSPATH with the older one winning; shaded/relocated org.apache.hadoop classes.

Common situations: Embedding frameworks (Spark, Hive, Flink) shipping their own Hadoop jars while LD_LIBRARY_PATH points at the cluster's libhdfs.so; stale CLASSPATH environment variables; partial cluster upgrades.

Related errors

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/a2c6249e0f2927c2. Report an issue: GitHub.