Posted By:
Gary_Feldman
Posted On:
Friday, September 7, 2001 10:43 AM
I have an existing C++ library that I need to make available from Java. The library itself is not multithreaded, but it has some global data that it protects using Posix (i.e. native) mutexes. I have no problem with the JNI layer making the library callable, with the exception of the synchronization. As near as I can tell, the right way to integrate this is to use MonitorEnter/Exit calls. The problem with this is that I don't have the JNIEnv available at that point in the code, and to make it directly available, I'd have to propagate it through many layers of calls. The one possible workaround that I have is to use JNI_GetCreatedJavaVMs to get the VM pointer, and then use GetEnv to get the JNIEnv.
More>>
I have an existing C++ library that I need to make available from Java. The library itself is not multithreaded, but it has some global data that it protects using Posix (i.e. native) mutexes. I have no problem with the JNI layer making the library callable, with the exception of the synchronization.
As near as I can tell, the right way to integrate this is to use
MonitorEnter/Exit
calls. The problem with this is that I don't have the JNIEnv available at that point in the code, and to make it directly available, I'd have to propagate it through many layers of calls.
The one possible workaround that I have is to use
JNI_GetCreatedJavaVMs
to get the VM pointer, and then use
GetEnv
to get the JNIEnv. This seems to rely on the current constraint of only one VM per process. However, I don't know if that constraint applies to platforms other than Sun's (with the obvious example, for me at least, being WebLogic). Also, this seems to be a temporary solution, as the design of
JNI_GetCreatedJavaVMs
clearly shows an intent to have more than one VM in the future, but with no easy global way to find the current VM (or JNIEnv, for that matter).
Any suggestions or corrections would be welcome.
Gary
<<Less