We are willing to communicate to a C++ library developed by another team from Java.
The natural and most optimal approach we've seen is using JNI, but use SWIG for simplicity during the developing time.
We actually have developed the prototype and is working well. There is also a C++->Java communication after the first Java->c++ communication using SWIG Directors.
The major problem we've seen is to be exposed to possible errors in C++ library, such as memory corruption and memory leaks.
It seems there is no way to effectively protect against these errors. For example, executing an abort (simulating some incorrect memory operation) in C++ will kill the JVM
The solution we've thought is to launch several java processes out of the parent JVM that will run in JBoss and that is what we are willing to protect.
Launching java process is hard, basically because a JVM is needed to start first.
In this case, the solution we've thought is to use several Nailgun servers. Each one will load a JVM ad will have access (in the classpath) to the programs we want to launch.
Each JVM in each Nailgun Server (the relation is 1-1) is capable to run concurrently several executions of our program in the same JVM. If some error occurs all the executions in this Nailgun JVM will crash (but the JBoss JVM will be alive). For this reason we scheduled to have several Nailgun servers with limited number of executions and use some kind of load balancing to dispatch the executions to any of the servers. Additionally the Nailgun servers will be restarted periodically to prevent from memory leaks.
We think this is a good approach to protect from C++ crashes.
However we want to ask the community if there is some better approach.
I forgot to mention that another solution we are considering is to have a clustered JBoss with our war for fail-over reasons. And then maybe incorporate the Nailgun server or not depending on the C++ program reliability. The benefit of a pure JBoss clustered application (without Nailgun processes) is that we will not need any kind of interprocess communication, the entire operation will be executed in a process with threads.
Sometimes the simplest way to protect your Java process from the risks of third-party native code is to run the risky code in a separate process.
However, this may require inter-process communication, which can add cost and complexity.