java-native-access/jna · critical

JNA: Problems loading core IDs: %s

Error message

JNA: Problems loading core IDs: %s

What it means

During native library load, after obtaining a JNIEnv, JNA runs JNA_init() to cache core class/method/field IDs (Pointers, Memory, Structures, etc.). If JNA_init returns an error string, JNA prints this message with the detail, sets the load result to 0, and aborts initialization — every subsequent JNA native call will fail or misbehave because cached IDs are missing.

Source

Thrown at native/dispatch.c:3364

  return newJavaString(env, CHECKSUM, CHARSET_UTF8);
}

JNIEXPORT jint JNICALL
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[] = {

View on GitHub (pinned to d036ad9781)

Solutions

1. Delete stale extracted native libraries (e.g. os-arch temp dirs, jna.*.tmp) and restart so the native lib matches the jna.jar version.
2. Ensure a single consistent JNA version on the classpath (run mvn dependency:tree / gradle dependencies and exclude transitive older JNA).
3. If running under the module system, open/expose com.sun.jna packages so the native layer can resolve the classes.
4. Read the %s detail in the message — it names the exact missing ID — and align the bundled native dispatch binary with jna.jar.

Example fix

// before: mixed versions
// pom: jna 5.13.0 + transitive jna-platform 5.4.0 with old bundled dispatch
// after: pin and exclude
<dependency>
  <groupId>net.java.dev.jna</groupId>
  <artifactId>jna</artifactId>
  <version>5.14.0</version>
</dependency> <!-- exclude other jna artifacts transitively -->

// Verify a single consistent JNA version before load:
String pkgVersion = com.sun.jna.Native.class.getPackage().getImplementationVersion();
if (pkgVersion == null || !pkgVersion.equals(EXPECTED_JNA_VERSION)) {
  throw new IllegalStateException("JNA version mismatch on classpath: " + pkgVersion);
}

When it happens

Trigger: JNA_init cannot find expected classes/methods via JNI FindNative/GetMethodID — e.g. a mixed JNA version install where the native dispatch library binary is from a different JNA release than jna.jar, or classes are missing from the boot/module path.

Common situations: Upgrading jna.jar without replacing the cached/extracted native dispatch library (stale jna dispatch .so/.dll in tmp or bundled); fat jars mixing JNA versions; module-path setups hiding com.sun.jna classes from JNI lookup.

Related errors

• JNA: Problems loading callback IDs: %s
• JNA: Can't attach native thread to VM on load
• JNA: could not detach thread on initial load
• There is an incompatible JNA native library installed on thi
• JNA: could not detach thread after callback init

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