What causes "No method method.getName() with signature sig in cls" in java-native-access/jna?

Verify the native library actually exports the function (nm -D libfoo.so / dumpbin /exports) with the exact name.

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

No method method.getName() with signature sig in cls

Error message

No method method.getName() with signature sig in cls

What it means

JNA throws this UnsatisfiedLinkError when the native library was loaded but does not export a function matching the Java method's name and JNI-style signature. The Java side registered the method, but the native symbol lookup or signature match failed inside the native dispatcher.

Source

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

                if (LastErrorException.class.isAssignableFrom(etypes[e])) {
                    throwLastError = true;
                    break;
                }
            }

            Function f = lib.getFunction(method.getName(), method);
            try {
                handles[i] = registerMethod(cls, method.getName(),
                                            sig, cvt,
                                            closure_atypes, atypes, rcvt,
                                            closure_rtype, rtype,
                                            method,
                                            f.peer, f.getCallingConvention(),
                                            throwLastError,
                                            toNative, fromNative,
                                            f.encoding);
            } catch(NoSuchMethodError e) {
                throw new UnsatisfiedLinkError("No method " + method.getName() + " with signature " + sig + " in " + cls);
            }
        }
        synchronized(registeredClasses) {
            registeredClasses.put(cls, handles);
            registeredLibraries.put(cls, lib);
        }
    }

    /**
     * Get the {@link NativeLibrary} instance that is wrapped by the given
     * {@link Library} interface instance.
     *
     * @param library the {@link Library} interface instance, which was created
     * by the {@link Native#load Native.load()} method
     * @return the wrapped {@link NativeLibrary} instance
     */
    public static NativeLibrary getNativeLibrary(final Library library) {
        if(library == null) {

View on GitHub (pinned to d036ad9781)

Solutions

Verify the native library actually exports the function (nm -D libfoo.so / dumpbin /exports) with the exact name.
Check that the register()/load() call binds the correct library file and version.
Align the Java method signature (types and arity) with the native function; use A or _A name mapping only if the native symbol is mangled/annotated.
Rebuild or redeploy the native library so it matches the Java interface.

Example fix

// before: Java expects foo(int) but native exports only foo_long
native long foo(int x);
// after: match the actual export
native long foo(long x);

Defensive patterns

Strategy: try-catch

Validate before calling

// Verify the symbol exists before binding (Unix)
Process p = new ProcessBuilder("sh", "-c",
    "nm -D " + libPath + " | grep -w " + functionName).start();
if (p.waitFor() != 0) throw new IllegalStateException(
    functionName + " missing from " + libPath);

Try / catch

try {
    result = myNative.compute(x);
} catch (UnsatisfiedLinkError e) {
    if (e.getMessage().startsWith("No method ")) {
        LOG.error("Native function missing or signature mismatch: {}", e.getMessage());
        throw new NativeBindingException("Library version mismatch", e);
    }
    throw e;
}

Prevention

Pin and verify the native library version alongside the Java interface jar.
Smoke-test every bound function at startup.
Keep the C header and Java interface in sync (generate bindings when possible).
Check exported symbol names with nm/dumpbin when the library changes.

When it happens

Trigger: Calling a method on a registered (Native.register direct-mapping) class whose native library lacks a function of that name/arity, or whose argument signature does not match what JNA derived.

Common situations: Version mismatch between the .so/.dll and the Java interface (function renamed or added later); wrong library mapped to the class; typos or case-sensitivity on Linux; method overloads producing a signature the native side lacks.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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