apache/hadoop · error · RuntimeException

Native object create failed, class: {}

Error message

Native object create failed, class: {}

What it means

NativeBatchProcessor.init calls NativeRuntime.createNativeObject(nativeHandlerName), a JNI call that returns a native pointer (0 on failure). A 0 return means the JNI library is loaded but the C++ side could not instantiate the named handler class - typically the handler name is not registered in libnativetask.so, or the .so was built against a different version than the jars. init throws RuntimeException to fail fast before any native data flows.

Source

Thrown at hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-nativetask/src/main/java/org/apache/hadoop/mapred/nativetask/NativeBatchProcessor.java:120

      this.rawInputBuffer = input.getByteBuffer();
    }
    if (null != output) {
      this.out = output;
      this.rawOutputBuffer = output.getByteBuffer();
    }
  }

  @Override
  public void setCommandDispatcher(CommandDispatcher handler) {
    this.commandDispatcher = handler;
  }

  @Override
  public void init(Configuration conf) throws IOException {
    this.nativeHandlerAddr = NativeRuntime
        .createNativeObject(nativeHandlerName);
    if (this.nativeHandlerAddr == 0) {
      throw new RuntimeException("Native object create failed, class: "
          + nativeHandlerName);
    }
    setupHandler(nativeHandlerAddr, ConfigUtil.toBytes(conf));
  }

  @Override
  public synchronized void close() throws IOException {
    if (nativeHandlerAddr != 0) {
      NativeRuntime.releaseNativeObject(nativeHandlerAddr);
      nativeHandlerAddr = 0;
    }
    IOUtils.cleanupWithLogger(LOG, in);
    in = null;
  }

  @Override
  public long getNativeHandler() {
    return nativeHandlerAddr;

View on GitHub (pinned to 2add963021)

Solutions

1. Run 'hadoop checknative' to verify libnativetask.so is found and matches the distribution
2. Ensure the jars and libnativetask.so come from the exact same Hadoop build (reinstall or re-extract the release tarball)
3. If building custom handlers, confirm the C++ factory registration name matches nativeHandlerName exactly and rebuild the native library
4. As a stopgap, disable the native path (revert mapreduce.job.map.output.collector.class to the default MapOutputBuffer) so jobs proceed on the Java path

if (!NativeRuntime.isNativeLibraryLoaded()) {
  conf.unset("mapreduce.job.map.output.collector.class"); // Java fallback path
} else {
  // native path OK; handler must still be registered in the loaded libnativetask.so
}

try {
  processor.init(conf);
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Native object create failed")) {
    // handler not registered in this native build: realign jars/so or disable native path
    throw new IllegalStateException("Native handler unavailable; align native libs or disable nativetask", e);
  }
  throw e;
}

When it happens

Trigger: The nativetask pipeline constructs a NativeBatchProcessor for a handler name unknown to the loaded libnativetask.so; or mixing Hadoop distribution jars with native libraries from another build; or developing a custom native platform whose handler name was never registered in the C++ factory.

Common situations: Replacing hadoop jars without updating lib/native; tarball installs where HADOOP_HOME points at mismatched native dirs; custom nativetask platform development where the Java-side handler name and the C++ REGISTER_HANDLER names drift.

Related errors

• (unable to get root cause for %s)
• (unable to get stack trace for %s)
• could not find method %s from class %s with signature %s
• NativeRuntime cannot be loaded, please check that libnativet
• Native output collector cannot be loaded;

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