java-native-access/jna · critical

JNA: Problems loading callback IDs: %s

Error message

JNA: Problems loading callback IDs: %s

What it means

After core IDs initialize, JNA runs JNA_callback_init() to cache method IDs for callback dispatch (ffi_callback_invoke and related). If this step fails it returns an error string; JNA prints this message with the detail and marks native load as failed (result 0). Callback-based native interop will not function, even if non-callback JNA calls might partially work.

Source

Thrown at native/dispatch.c:3368

JNI_OnLoad(JavaVM *jvm, void *UNUSED(reserved)) {
  JNIEnv* env;
  int result = JNI_VERSION_1_4;
  int attached = (*jvm)->GetEnv(jvm, (void *)&env, JNI_VERSION_1_4) == JNI_OK;
  const char* err;

  if (!attached) {
    if ((*jvm)->AttachCurrentThread(jvm, (void *)&env, NULL) != JNI_OK) {
      fprintf(stderr, "JNA: Can't attach native thread to VM on load\n");
      return 0;
    }
  }

  if ((err = JNA_init(env)) != NULL) {
    fprintf(stderr, "JNA: Problems loading core IDs: %s\n", err);
    result = 0;
  }
  else if ((err = JNA_callback_init(env)) != NULL) {
    fprintf(stderr, "JNA: Problems loading callback IDs: %s\n", err);
    result = 0;
  }
  if (!attached) {
    if ((*jvm)->DetachCurrentThread(jvm) != 0) {
      fprintf(stderr, "JNA: could not detach thread on initial load\n");
    }
  }

  return result;
}

JNIEXPORT void JNICALL
JNI_OnUnload(JavaVM *vm, void *UNUSED(reserved)) {
  jobject* refs[] = {
    &classObject, &classClass, &classMethod,
    &classString,
#ifndef NO_NIO_BUFFERS
    &classBuffer, &classByteBuffer, &classCharBuffer,

View on GitHub (pinned to d036ad9781)

Solutions

1. Clear cached native libraries and repack/redeploy with a single, consistent JNA version (jar and native dispatch from the same release).
2. Check the %s detail to see which callback ID failed to resolve and confirm that class/method exists in the shipped jna.jar.
3. If using shading/relocation, keep com.sun.jna unshaded or configure the shading plugin to preserve it.
4. Test with a minimal program (a single Callback registration) in a clean JVM to isolate classpath vs native-binary causes.

Example fix

// before: uber-jar shaded com.sun.jna into com.myapp.shaded.jna
<relocation><pattern>com.sun.jna</pattern><shadedPattern>com.myapp.shaded.jna</shadedPattern></relocation>
// after: exclude JNA from relocation
<relocation><pattern>com.sun.jna.internal.*</pattern> ... <!-- keep com.sun.jna untouched -->

// Smoke-test callback dispatch immediately after startup:
Callback probe = () -> {};
if (!callbackRegistry.add(probe)) {
  throw new IllegalStateException("JNA callback dispatch not initialized correctly");
}

When it happens

Trigger: JNA_callback_init cannot resolve the Callback class hierarchy or its ffi_callback_invoke method via JNI GetMethodID — typically due to a JNA jar/native-version mismatch, or com.sun.jna.Callback being invisible to the native lookup (classpath/module issues).

Common situations: Partially upgraded deployments where jna.jar was updated but the native library cached from an older version; shaded/uber jars that renamed or dropped com.sun.jna classes; security manager or classloader isolation hiding JNA internals.

Related errors

• JNA: Problems loading core IDs: %s
• JNA: could not detach thread after callback init
• JNA: Can't attach native thread to VM for closure handler
• JNA: Out of memory: Can't allocate local frame
• JNA: callback object has been garbage collected

AI-assisted analysis of java-native-access/jna@d036ad9781 (2026-09-12). Data as JSON: /api/errors/cffeee089feaf024. Report an issue: GitHub.