java-native-access/jna · warning
JNA: Unhandled arg conversion type
Error message
JNA: Unhandled arg conversion type %d
What it means
In invoke_callback's argument conversion loop, an unrecognized conversion flag (cb->conversion_flags[i]) hits the default case and JNA prints this diagnostic to stderr, skipping conversion for that argument. The Java callback will then receive an incorrectly or unconverted argument value.
Solutions
- Ensure the native jnidispatch binary version exactly matches the JNA jar version.
- Change the callback parameter types to supported ones (primitives, Pointer, Structure, String/WString, NativeMapped).
- Rebuild/refresh the native library if a custom or stale build is deployed.
Example fix
// before void cb(CustomJavaType t); // no native conversion flag // after void cb(Pointer p); // supported conversion type
Defensive patterns
Strategy: validation
Validate before calling
// Verify at startup that jnidispatch native version matches the JNA jar Native.getNativeVersion(); // compare against com.sun.jna.Version
Prevention
- Ship the jnidispatch native binary bundled from the exact JNA version used
- Restrict callback parameters to supported conversion types
- Rebuild/redeploy consistently when upgrading JNA
- Watch stderr for 'Unhandled arg conversion type' during integration tests
When it happens
Trigger: A callback declaration whose parameter type maps to a conversion flag the native layer does not handle (unsupported/unknown CVT_* flag) — typically from a mismatch between the Java callback signature and what native setup computed, or a JNA build/version mismatch.
Common situations: Mixed native library (libjnidispatch) and Java JNA jar versions; callback parameter types that aren't in the supported conversion set.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- JNA: callback object has been garbage collected
- JNA: error handling callback exception, continuing
- JNA: Likely memory leak here
- Callback argument <nativeParamTypes[i]> requires custom…
- Callback method is inaccessible, make sure the interface is…
AI-assisted analysis of java-native-access/jna@d036ad9781 (2026-09-12).
Data as JSON: /api/errors/3e72bc4adbec206d.
Report an issue: GitHub.
Appendix: source
Thrown at native/callback.c:462
case CVT_CALLBACK:
*((void **)args[i+3]) = newJavaCallback(env, *(void **)cbargs[i], cb->arg_classes[i]);
break;
case CVT_FLOAT:
args[i+3] = alloca(sizeof(double));
*((double *)args[i+3]) = *(float*)cbargs[i];
break;
case CVT_SHORT:
args[i+3] = alloca(sizeof(int));
*((int *)args[i+3]) = *(short*)cbargs[i];
break;
case CVT_BYTE:
args[i+3] = alloca(sizeof(int));
*((int *)args[i+3]) = *(char*)cbargs[i];
break;
case CVT_DEFAULT:
break;
default:
fprintf(stderr, "JNA: Unhandled arg conversion type %d\n", cb->conversion_flags[i]);
break;
}
}
}
if (cb->rflag == CVT_STRUCTURE_BYVAL) {
resp = alloca(sizeof(jobject));
}
else if (cb->cif.rtype->size > cif->rtype->size) {
resp = alloca(cb->cif.rtype->size);
}
#define FPTR(ENV,OFFSET) (*(void **)((char *)(*(ENV)) + OFFSET))
#define JNI_FN(X) ((void (*)(void))(X))
ffi_call(&cb->java_cif, JNI_FN(FPTR(env, cb->fptr_offset)), resp, args);
if ((*env)->ExceptionCheck(env)) {
jthrowable throwable = (*env)->ExceptionOccurred(env);
(*env)->ExceptionClear(env);
if (!handle_exception(env, self, throwable)) {View on GitHub (pinned to d036ad9781)