I use Java JNI with Gdal. There are some server side applications built on top of the JNI bindings. The whole JVM stackfalls if there is an error in the JNI section.
What's the best way of testing that a c/c++ library does not contain fatal errors which will cause JVM stackfall ? What is the best practice to cleanly deal with errors which do arise ?
Have you got these JVM settings turned on?
-verbose:jni -Xcheck:jni
I find them invaluable for initial development of JNI code.
The -Xcheck:jni option activates a set of wrapper functions around the JNI functions. The wrapper functions perform checks on the incoming parameters. These checks include:
* Whether the call and the call that initialized JNI are on the same thread.
* Whether the object parameters are valid objects.
* Whether local or global references refer to valid objects.
* Whether the type of a field matches the Get<Type>Field or Set<Type>Field call.
* Whether static and nonstatic field IDs are valid.
* Whether strings are valid and non-null.
* Whether array elements are non-null.
* The types on array elements.
Two things come to mind:
1). If you have any possibility to run the C++ code as a separate process (use any RPC technique to communicate) then you dodge this problem, albeit at the expense of performance.
2). You are at the mercies of the C++/JNI developer. Most problems I've encourntered are at the "skin" of the JNI layer. That is, I had a reasonbably stable, existing library which I wrapped in JNI. The library would get upset if I inadvertantly passed null pointers to the existing code, and if I failed to check for nulls in response I could also have issues. So we put a lot of effort into sanitising that wrapper layer. Anywhere where there was a possibility for unexpected results we added checking.
Of course if the whole library is new, then life is harder - in the end you simply have to produce robust code.