java-native-access/jna · error · java.lang.IllegalStateException

Neither the StackWalker, nor the SecurityManager based getCa

Error message

Neither the StackWalker, nor the SecurityManager based getCallingClass implementation are useable; you must explicitly provide the class to register

What it means

Native.register() has two inference strategies: StackWalker (preferred) and the SecurityManager getClassContext fallback. If neither mechanism is available or usable on the runtime — StackWalker cannot produce the caller class and the SecurityManager path failed or was not attempted — JNA throws this final IllegalStateException telling the caller to provide the class explicitly.

Source

Thrown at src/com/sun/jna/Native.java:1645

        if (securityManagerExposerConstructor != null) {
            Class<?>[] context = null;
            try {
                Object securityManagerExposer = securityManagerExposerConstructor.newInstance();
                context = (Class<?>[]) securityManagerGetClassContext.invoke(securityManagerExposer);
            } catch (Throwable ex) {
                LOG.log(Level.WARNING, "Failed to invoke SecurityManagerExposer#<init> or SecurityManagerExposer#getClassContext", ex);
            }

            if (context == null) {
                throw new IllegalStateException("The SecurityManager implementation on this platform is broken; you must explicitly provide the class to register");
            }
            if (context.length < 4) {
                throw new IllegalStateException("This method must be called from the static initializer of a class");
            }
            return context[3];
        }

        throw new IllegalStateException("Neither the StackWalker, nor the SecurityManager based getCallingClass implementation are useable; you must explicitly provide the class to register");
    }

    /**
     * Set a thread initializer for the given callback.
     * @param cb The callback to invoke
     * @param initializer The thread initializer indicates desired thread configuration when the
     * given Callback is invoked on a native thread not yet attached to the VM.
     */
    public static void setCallbackThreadInitializer(Callback cb, CallbackThreadInitializer initializer) {
        CallbackReference.setCallbackThreadInitializer(cb, initializer);
    }

    private static final Map<Class<?>, long[]> registeredClasses = new WeakHashMap<>();
    private static final Map<Class<?>, NativeLibrary> registeredLibraries = new WeakHashMap<>();

    private static void unregisterAll() {
        synchronized(registeredClasses) {
            for (Map.Entry<Class<?>, long[]> e : registeredClasses.entrySet()) {

View on GitHub (pinned to d036ad9781)

Solutions

1. Always pass the class: Native.register(MyLib.class) or Native.register(libName, MyLib.class) — the explicit overload never uses stack inference.
2. Upgrade JNA to the latest 5.x release so the StackWalker path works on your JDK.
3. If you must use inference, register from the static initializer of the declaring class on a JDK with working StackWalker.
4. Wrap registration in a compatibility check and fall back to the explicit-class form when the runtime is detected as restricted.

Example fix

// before
static { Native.register("mylib"); } // no usable inference on this runtime

// after
static { Native.register("mylib", MyLib.class); }

boolean stackUsable;
try {
    StackWalker.getInstance().getCallerClass();
    stackUsable = true;
} catch (Throwable t) { stackUsable = false; }
if (!stackUsable) {
    Native.register("mylib", MyLib.class); // explicit: works everywhere
}

try {
    Native.register("mylib");
} catch (IllegalStateException e) {
    if (e.getMessage().contains("Neither the StackWalker, nor the SecurityManager")) {
        Native.register("mylib", MyLib.class);
    } else { throw e; }
}

When it happens

Trigger: Calling Native.register() with no explicit Class on a runtime where both inference paths fail: restricted StackWalker usage, SecurityManager unsupported (modern JDKs), or exotic/embedded JVMs lacking either mechanism.

Common situations: JDK 24+ (SecurityManager removed) with an old JNA whose StackWalker fallback also misbehaves, GraalVM native-image with pruned stacks, or sandboxed environments restricting stack access.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• The SecurityManager implementation on this platform is broke
• Can't determine class with native methods from the current c
• This method must be called from the static initializer of a
• No support for " + os
• Set sun.java2d.noddraw=true to enable transparent windows

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