JNI Callback from remote process

Question

I have an application that calls back from C to Java in multiple situations. In some, I have been successful using the technique of calling AttachCurrentThread as described, for example, in various places, e.g.,
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniref.html#invoke
and recently in this forum
http://forum.java.sun.com/thread.jspa?threadID=763205&tstart=45`
This is an accessibility application and one of the situations I need to callback from is a global keyboard hook. In this context, I call from Java to a C DLL which sets up the keyboard hook using the standard Windows procedure SetWindowsHookEx.
      SetWindowsHookEx(    
                  WH_KEYBOARD,    // type of hook to install
                 (HOOKPROC) mykeyboardProc,    // address of hook procedure
                ( HINSTANCE__* )hDll,    // handle of application instance
                0     // identity of thread to install hook for  (all threds)      );The keyboard hook functions in Windows by being "injected" into running applications so that it runs in their process space and therein, apparently, lies the problem.
The keyboard hook gets callbacks from Windows whenever a key is pressed. This is the information I want to learn about back in Java. Our current approach is to have the keyboard hook write the key data to shared memory. Then the Java application makes polling calls into the previously mentioned C DLL which checks the shared memory and returns anything it finds. The C DLL is compiled with the current MinGW compiler.
This procedure works alright-- I can access the information using shared memory in C and polling that from Java. It is, however, a tad slow. I'd like to use a callback from C directly to eliminate the extra layer of polling. I could, of course, do the polling in the C DLL and call back to Java from there. That would eliminate a process switch every time we poll, but would still leave the polling.
In my attempts to set up a direct callback from the keyboard hook to Java, the C code uses AttachCurrentThread using the env pointer obtained from the JNI_OnLoad method. When my application has the focus and I type, I get print statements from the C DLL and the callbacks work fine. When any other application has focus, the callback does not work and there are no print statements. In fact, the keyboard hook crashes and stops responding to any key events.
Since I do not get print statements when another application has focus (or they go into the ether), I do not know directly whether the JNI_OnLoad function actually gets called each time the DLL is loaded into another application. However, the JVM pointer I cache in the JNI_OnLoad function is NULL when I get a key event callback (when another application has focus). I tested this by putting an "exit" call if the cached JVM was NULL in the keyboard procedure (mykeyboardProc above). When any application has focus and I type a key, that application exits. From this I assume that JNI_OnLoad is not getting called, but since the cached JVM is NULL, that is irrelevant.
One option I have attempted is to use JNI_GetCreatedJavaVMs to get a list of the JVMs running on the machine. From this, I hoped to somehow deduce which JVM was running my application and use its pointer. However, despite putting some of the the directories` with the jvm.dll into my library path:
   g++ -I/c/Programs/Java/JDK15~1.0_0/include
       -I/c/Programs/Java/JDK15~1.0_0/include/win32
       -L/c/Programs/Java/JDK15~1.0_0/jre/bin \
       ....I get the error:
undefined reference to `JNI_GetCreatedJavaVMs@12'
I would be grateful for any suggestions or solutions.
Rick

Answer 1

Thanks for the reply Jim,
I've been compiling in the Msys environment.
I created the jvm.def and generated the jvm.a as you
suggested.
This apparently required copying the jvm.dll from
/c/Programs/Java/JDK15~1.0_0/jre/bin/client
de]
to my working directory.  Before I did that I got a
message
about stripping the path components from the dll
name.
Then I tried to make the DLL in the fashion I had
been:g++ -I/c/Programs/Java/JDK15~1.0_0/include \
-I/c/Programs/Java/JDK15~1.0_0/include/win32 \
L/c/Programs/Java/JDK15~1.0_0/jre/bin/client \
-shared -o JKeyboardInterface.dll \     
jvm.a \
JKeyboardInterface_wrapper.cpp \
JKeyboardDllMain.cpp \
JKeyboardInterface.cpp \
-Wl,--out-implib,libJKeyboardInterface.a \
     -Wl,--add-stdcall-alias -mno-cygwin \
-fno-rtti -fno-exceptions -s
This resulted in this error:
Creating library file: libJKeyboardInterface.a
K:/DOCUME~1/rick/LOCALS~1/Temp/ccU1daaa.o:JKeyboardInt
erface.cpp:(.text+0xafb):
undefined reference to
`_imp__JNI_GetCreatedJavaVMs@12'
collect2: ld returned 1 exit status
Hmmmmm. What happens if you remove the '-Wl,--out-implib,libJKeyboardInterface.a'? It seems to be failing in the step creating the static lib, which may prevent the DLL from being properly created.
Since this was a different undefined reference, I
re-did the jmv.def step
using imp_JNI_GetCreatedJavaVMs@12 instead of
JNI_GetCreatedJavaVMs@12
This generated the same error.Yeah. I'm sure I never had to do anything like that.
>
Then I tried to use dllwrap with both versions of the
jvm.a generated above::
dllwrap --driver-name=c++ \
--add-stdcall-alias \
-o JKeyboardInterface.dll \
       jvm.a \
       JKeyboardInterface_wrapper.cpp \
       JKeyboardDllMain.cpp \
       JKeyboardInterface.cpp \With both versions of the jvm.a, I got the error:
K:/DOCUME~1/rick/LOCALS~1/Temp/ccSccaaa.o:JKeyboardInt
erface.cpp:(.text+0xafb):
undefined reference to `JNI_GetCreatedJavaVMs@12'
ollect2: ld returned 1 exit statusI'm not clear why the two approaches (g++ -shared and
dllwrap) yield different reference problems.
I've read that dllwrap is "deprecated" Probably.
(http://www.mingw.org/MinGWiki/index.php/dllwrap).
Do you have any other suggestions about how to do
this?Have a look at:
http://www.inonit.com/cygwin/
Msys (which is Mingw) follows cygwin pretty closely.
I'm not near a Windows machine to try this at the moment. All I can say is that I have an application using CreateJavaVM, compiled with MSYS and it works. CreateJavaVM has the same problems as GetCreatedJavaVMs that you are seeing. The root cause is that the jvm.lib shipped with the JDK for Windows is not compatible with GCC. Hence the need to create the jvm.a library.
I build my code using an ANT script. It build the objects first and then links them. Deciphering the build script, it looks like the two steps would have the following command line syntax:
Compile to object files:
gcc -D REENTRANT -I <paths to include> somefiles.cpp somefiles.c
(I have a mix of C and C++)
Link object files to create DLL:
gcc -shared -D REENTRANT --kill-at -lstdc++ somefiles.o jvm.a
Try it in two steps and see if it makes a difference.
>
Is trying to use GetCreatedJavaVMs the correct
approach here?
If more than one exists, how do I determine which one
I want to attach to and get an env pointer for?From you original post, it is difficult to understand exactly what you are trying to achieve.
It seems like you are starting with a Java app that calls into some native code to create the keyboard hook. This hook will then call a callback method in native code when a key is pressed. You want the Java code to see this and act appropriately.
In Java callbacks are usually handled with events. Just have your native code fire an event in Java and have a Listener on the Java side. I do this in some of my code. Say I have an event called FooEvent and a listener called FooListener. There is also an object called Bar which can fire FooEvents and have FooListeners attached to it. The Bar class has an addFooListener() method which is actually a native method. The native implementation sets up the callback stuff on the native side. When an event occurs on the native side, the callback function is called and it does something like this:
jclass cls;
jmethodID mid;
cls = env->GetObjectClass(javaSource);
mid = env->GetMethodID(cls, "fireSomeEvent", "()V");
env->CallVoidMethod(javaSource, mid);In the code above, the 'cls' variable would be the Bar class object and the 'javaSource' variable is a global reference ot the Bar object to which the event listener was added. The 'env' variable is acquired by calling 'AttachCurrentThread' on a cached JavaVM pointer stored in a global reference.
The Bar class has a fireSomeEvent() method, which calls the event listeners using the event generator idiom:
http://www.javaworld.com/javaworld/jw-09-1998/jw-09-techniques.html
The listener on the Java side gets notification when the event occurs and you can take the appropriate action. No polling, no shared memory.
Jim S.