JNI, global variables in the C side module
Hany Louis Milika
i'm using jni between java and c, in the c side, i have a module that
includes some global variables, on the java side i create many instances
of a class that loads this c module, unfortunatly the shared library is
loaded only once, not one per each object.
so i become to the problem of having all the created java object
reference to the same module, and hence the same , global variables
any ideas to solve this?
i thought of soem ideas, btu didn't work till now
one of themis making a C++ class that holds the global variables in the
C code, and creating one C++ object per each created java object .. (but
till now i had no luck making the JNI work with C++, exactly at the
point "new Myclass() " )
tried also to make threads on the java side hopfully different copies of
the shared library woudl be loaded with each thread, but this didn't
work also
would appriciate any suggestions, ideas, (and even guidance regarding
the jni with C++ , creating new objects)
if this woudl be helpful, system here is sun solaris 7, jdk 1.2.2 ,
compilers used CC, g++
Joseph Millar
wrote:
> hi
> i'm using jni between java and c, in the c side, i have a module that
> includes some global variables, on the java side i create many instances
> of a class that loads this c module, unfortunatly the shared library is
> loaded only once, not one per each object.
Shared libraries are only loaded once per process, in
any context, not just Java.
> so i become to the problem of having all the created java object
> reference to the same module, and hence the same , global variables
Well, you shouldn't be using globals in this instance.
Globals are a sin, unless you have a very specific
truely global need. In your case you need many instances
of the same set of variables. In C, I'd use a struct
or in C++ a class (kinda the same, huh?), and maintain
some kind of list or some way to getting to the proper
struct/object when the native method is called.
> any ideas to solve this?
> i thought of soem ideas, btu didn't work till now
> one of themis making a C++ class that holds the global variables in the
> C code, and creating one C++ object per each created java object .. (but
> till now i had no luck making the JNI work with C++, exactly at the
> point "new Myclass() " )
The idea is sound. JNI works with both C and C++. The syntax
to call the JNI functions varies a little from one to the other,
but I have used both extensively and they work fine. What kind
of problems are you having? If you can give some specifics, we
should be able to get you on your way. It sounds like maybe
your code is named .c and not .cpp, in which case the compiler
is going to complain unless you override default behavior.
Need more info here.
> tried also to make threads on the java side hopfully different copies of
> the shared library woudl be loaded with each thread, but this didn't
> work also
As you found this won't work unless your native code is smart
enough to keep these "globals" in thread local storage.
--Joe
________________________________________________________________
Joseph A. Millar <jmi...@mediaone.net>
"Very funny, Scotty! Now beam down my clothes!" - James T. Kirk
Joseph Millar
wrote:
> private native void createX();
and
>JNIEXPORT jint JNICALL Java_X_createX(JNIEnv *, jobject)
These two do not match. Your Java definition of the native
method says nothing is returned, yet you are returning
something. This is seriously going to screw up the stack.
A crash is likely. Without exception, this function def
should match the one in the javah generated header.
Another item is your C++ files should be named .hpp and .cpp.
While this may look like a trivial thing, in fact it signals
many things to the compiler.
You linking errors about libC.so are odd, it sounds like you
have some kind of corrupted install. The compiler/linker
should know what version fo libC.so to go after and if it's
not there, you would get errors.
As for the unreferenced symbol error, I have no idea what
causes that. My experience on Solaris is limited, and I
have never seen that error before.
I would also remove the "cout<<"hi"" until such time as you
get other things working. IT just adds a problem area to
something that's already having trouble.
Hope this helps.