java-native-access/jna · warning

JNA: Unhandled arg conversion type %d

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.

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)

Solutions

1. Ensure the native jnidispatch binary version exactly matches the JNA jar version.
2. Change the callback parameter types to supported ones (primitives, Pointer, Structure, String/WString, NativeMapped).
3. 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

// Verify at startup that jnidispatch native version matches the JNA jar
Native.getNativeVersion(); // compare against com.sun.jna.Version

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
• Win32Exception(rc)
• Win32Exception(Kernel32.INSTANCE.GetLastError())

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