CODEWITHSUNDEEP
javajava-native-interface
zfgo
zfgo

Reputation: 355

In JNI, can you pass a C integer parameter to a Java primitive int?

I have a Java method that wish to be called from some Native method:

    public void onDownloadProgress(int current, int total) {

    }

and I am trying to call the above Java method from a native method:

    int current = ...
    int total = ...
    jni_callVoidMethod(
        env,
        jDownloadCallback,
        "onDownloadProgress",
        "(II)V",
        current,
        total
    );

jni_callVoidMethod is a helper method and its implementation is:

    void jni_callVoidMethod(JNIEnv *env, jobject receiver, const char *methodName, const char *contract, ...) {
        jclass clazz = env->GetObjectClass(receiver);
            if (NULL != clazz) {
            jmethodID method = env->GetMethodID(
            clazz,
            methodName,
            contract
        );
        if (NULL != method) {
            BUILD_VARARGS()
                env->CallVoidMethodV(
                receiver,
                method,
                va_args
            );
        if (env->ExceptionCheck()) { // prints out the exception if one is present
            env->ExceptionDescribe();
            env->ExceptionClear();
        }
        va_end(va_args);
        }
        env->DeleteLocalRef(clazz);
    }
}

However, in the Java method I am getting some very weird int values. For example, 3840120912. I am wondering can you directly send a C int to a Java primitive int instead of declaring the parameters in the Java method to become Integer type? Declaring those two parameters to be Integer works for me and I am getting the correct value.

Edit: Implementation of the BUILD_VARARGS macro:

#define BUILD_VARARGS() \
va_list va_args; \
va_start(va_args, contract); \
const char *cur = contract; \
while ('\0' != *cur && '(' != *cur) { /* skip to opening paren */ \
    cur++; \
} \
while ('\0' != *cur && ')' != *cur) { /* stop at closing paren */ \
    switch (*cur) { \
        case 'Z': \
            va_arg(va_args, int); /* bool (unsigned 8-bit int) */ \
            break; \
        case 'B': \
            va_arg(va_args, int); /* byte (signed 8-bit int) */ \
            break; \
        case 'C': \
            va_arg(va_args, int); /* char (unsigned 16-bit int) */ \
            break; \
        case 'S': \
            va_arg(va_args, int); /* short (signed 16-bit int) */ \
            break; \
        case 'I': \
            va_arg(va_args, long long); /* int (signed 32-bit int) (must be passed in as a long long) */ \
            break; \
        case 'J': \
            va_arg(va_args, long); /* long (signed 64-bit int) */ \
            break; \
        case 'F': \
            va_arg(va_args, double); /* float (32 bits) */ \
            break; \
        case 'D': \
            va_arg(va_args, double); /* double (64 bits) */ \
            break; \
        case 'L': \
            /* fully-qualified-class */ \
            while (';' != *++cur && '\0' != *cur); /* advance to end of class declaration */ \
            /* FIXME breaks varargs, seems to not be needed va_arg(va_args, jobject); */ \
            break; \
        case '[': \
            /* TODO type type[] */ \
        case '(': \
            /* TODO ( arg-types ) ret-type  method type */ \
        default: \
            break; \
    } \
    cur++; \
}

Upvotes: 0

Views: 466

Answers (1)

Botje
Botje

Reputation: 30830

That explains everything! Your calls to va_arg consume the arguments and when CallVoidMethodV gets to it, it is reading from somewhere else in the stack. From the va_arg manual:

The va_arg() macro expands to an expression that has the type and value of the next argument in the call. The parameter ap is the va_list ap initialized by va_start().
Each call to va_arg() modifies ap so that the next call returns the next argument.

Instead, you should create the va_list and immediately hand it off to CallVoidMethodV:

va_list va_args;
va_start(va_args, contract);
env->CallVoidMethodV(receiver, method, va_args);
va_end(va_args);

Upvotes: 2

Related Questions