Возврат null из собственных методов с использованием JNI

Это старый вопрос, но я тоже задавал его минуту назад...

Вы говорите в своем вопросе:

return 0; // Does NOT work - doesn't crash, just slows everything down horrible.

На самом деле я только что попробовал с jintArray, так как это то, что мой код должен выделять и возвращать, если не произойдет ошибка (определяемая некоторыми критериями, не связанными с этой темой), и в этом случае он должен вернуть нулевой результат.

Бывает, что возврат NULL (определенный как ((void*)0)) работает отлично и интерпретируется как null при возвращении на сторону Java. Ухудшения характеристик я не заметил. И если бы я ничего не пропустил, возврат 0 без приведения void * ничего бы не изменил.

Поэтому я не думаю, что это было причиной замедления, с которым вы столкнулись. NULL выглядит вполне нормально, чтобы вернуть null.

ИЗМЕНИТЬ:

• Подтверждаю, возвращаемое значение не имеет ничего общего с выступлениями. Я только что протестировал один и тот же код, возвращающий нулевое значение с одной стороны, и его аналог, возвращающий объект (jintArray) с другой. Производительность аналогична для NULL, jintArray размера 0 и случайного jintArray из нескольких КБ, выделенных статически.

• Я также попытался изменить значение поля вызывающего класса и вернуть значение void примерно с теми же характеристиками. Очень-очень немного медленнее, вероятно, из-за кода отражения, необходимого для захвата этого поля и установки его.

• Все эти тесты были сделаны под Android, а не под Java standalones - может быть поэтому? (см. комментарии):

  • An API 17 x86 emulator running under HAXM
  • API 19, работающий в тех же условиях.
  • Два физических устройства API 19 — планшет Asus и Galaxy 5 — работают под управлением Dalvik.

В вашем коде есть некоторая асимметрия, которая бросилась мне в глаза: вы никогда не выбираете тип возвращаемого объекта, за исключением случаев, когда вы возвращаете «ничего». Очевидно, объект env решает, как разместить javaSrray, так почему бы не попросить его вернуть какой-нибудь пустой массив? Возможно, возвращаемый вами 0 нужно обрабатывать особым образом при маршалинге между jni и java.

Вы пытались вернуть ссылку NULL?

Это не проверено (в данный момент у вас нет под рукой среды разработки JNI), но вы должны иметь возможность создать новую глобальную ссылку на NULL и вернуть ее следующим образом:

return (*env)->NewGlobalRef(env, NULL);

РЕДАКТИРОВАТЬ При этом вы проверяете, возникает ли исключение, но не очищаете его. Это, насколько я понимаю, означает, что он все еще «выброшен» на уровень Java, поэтому вы должны иметь возможность использовать его как индикатор ошибки; тогда не имеет значения, что возвращает функция. На самом деле, вызов функции JNI, отличной от ExceptionClear()/ExceptionDescribe(), при возникновении исключения не является «безопасным» в соответствии с документацией. То, что функции "медленные", может быть вызвано тем, что функция ExceptionDescribe() записывает отладочную информацию.

Итак, если я правильно понимаю, это должна быть функция с хорошим поведением, выдающая исключение при первом возникновении ошибки и возвращающая NULL при каждом последующем вызове (пока «ошибка» не будет очищена):

if (error != ERROR) {
    jbyteArray javaArray = env->NewByteArray((jsize) message.size);
    env->SetByteArrayRegion(javaArray, 0, message.size, reinterpret_cast<jbyte*>(message.buffer()));
    if (env->ExceptionOccurred()) {
        error = ERROR;
        return 0;
    }
    return javaArray;
} else {
    return env->NewGlobalRef(NULL);
}

Опять же, это не проверено, поскольку сейчас у меня нет доступной среды JNI.