Java JNI предотвращение стека

Question

Я использую Java JNI с Gdal . Есть некоторые серверные приложения, построенные поверх привязок JNI. Весь стек JVM падает, если в разделе JNI есть ошибка.

Как лучше всего проверить, что библиотека c / c ++ не содержит фатальных ошибок, которые могут вызвать падение стека JVM? Какова наилучшая практика для аккуратного устранения возникающих ошибок?

Answer 1

На ум приходят две вещи:

1). Если у вас есть возможность запустить код C ++ как отдельный процесс (для связи используйте любой метод RPC), вы избежите этой проблемы, хотя и за счет производительности.

2). Вы находитесь в зависимости от разработчика C ++ / JNI. Большинство проблем, с которыми я столкнулся, находятся на «слое» слоя JNI. То есть у меня была достаточно стабильная, существующая библиотека, которую я обернул в JNI. Библиотека расстроится, если я случайно передам нулевые указатели в существующий код, и если мне не удастся проверить нулевые значения в ответ, у меня также могут возникнуть проблемы. Поэтому мы приложили много усилий для дезинфекции этого слоя оболочки. Везде, где была возможность непредвиденных результатов, мы добавили проверку.

Конечно, если вся библиотека новая, тогда жизнь сложнее - в конце концов, вам просто нужно создать надежный код.

Answer 2

Включены ли эти настройки JVM?

-verbose:jni -Xcheck:jni

Я считаю их бесценными для первоначальной разработки кода JNI.

Опция -Xcheck:jni активирует набор функций-оболочек для функций JNI. Функции-обертки выполняют проверку входящих параметров. Эти проверки включают в себя:

• Находятся ли вызов и вызов, который инициализировал JNI, в одном потоке.
• Являются ли параметры объекта действительными объектами.
• Местные или глобальные ссылки ссылаются на действительные объекты.
• Соответствует ли тип поля вызову Get<Type>Field или Set<Type>Field.
• Допустимы ли статические и нестатические идентификаторы полей.
• Являются ли строки допустимыми и ненулевыми.
• Являются ли элементы массива ненулевыми.
• Типы элементов массива.