NullPointerException during accessibility check about jnativehook

[kwhat]

Does this only happen when the library is used with JNLP, or does it happen when the demo is run normally?

[tinarm]

I can run my application normally without any problem, so it's only related to JNLP/javaws in my case.

[kwhat]

Yep, this was the correct project to report this to. I strongly suspect there is a *env->FindClass somewhere outside of the jni_Globals that is failing. It sounds like it is the NativeHookException class, but its going to be a while before I can check. For some reason JNI's FindClass fails when it is called outside of JNI_OnLoad when using JNLP. This is the reason for the jni_Globals.c file. I suspect JNLP is doing something to the default class loader, maybe for security, but I have haven't located much documentation on the topic besides this brief FAQ Item.

[tinarm]

Hopefully I might have some time to debug this issue.

[tinarm]

An I'm sorry for my initial information, it seems like the issue exists also in RC2. I found a log message where I've caught a NPE in thread "JNativeHook Native Dispatch", which has been renamed to "JNativeHook Native Hook" in RC3.

[tinarm]

I've tried to move all calls to (*env)->FindClass to jni_Globals.c without any luck, the same problem is still there. And I would suspect to get a NoClassDefFoundError instead of a NullPointerException if the FindClass fails.

[kwhat]

I will take a look today. Is there anyway to run JNLP without going thought the key store song and dance after 1.7u45?

[tinarm]

I don't think so, but I'm a JNLP novice. However, I've gone through the signing steps and haven't tried another way.

[kwhat]

I cannot duplicate the issue on Linux with Java 1.8. I cannot run JNLP on OS X with Java 1.7 because of the following error:

javaws -verbose ./test.jnlp 
No Java runtime present, requesting install.
Unable to locate a Java Runtime to invoke.

... and apparently you cannot use Java WebStart with OpenJDK 7 which is my 1.7 implementaiton on Linux.

I assume you tried to move the following FindClass into jni globals?

[tinarm]

Yes, I tried to move the FindClass in jni_Errors.c into jni globals.

I found a support page from Apple that's referenced from people getting the same error as you:
http://support.apple.com/en-us/HT202643

[kwhat]

I ended up reverting back to JDK 1.6 because it wouldn't work any other way. I suspect that Apple never went back and fixed javaws for 10.7 to account for the new JDK 1.7+ location. Either way, I cant seem to duplicate the problem using javaws from the command line and the following JNLP file. You are building from the trunk that includes that pull request you made? Do you get any meaningful ouput with the log level set to all? Strack trace? Are you using any custom Event Dispatcher?

<jnlp spec="1.0+" codebase="http://plutonium244/" href="jnativehook.jnlp">
<information>
    <title>JNativeHook Library</title>
    <vendor>Alexander Barker ([email protected])</vendor>
    <homepage href="https://github.com/kwhat/jnativehook" />
    <description kind="short">Global keyboard and mouse listeners for Java.</description>
    <offline-allowed />
</information>

<security>
    <all-permissions />
</security>
<resources>
    <j2se version="1.5+" />
    <jar href="jar/JNativeHook.jar" />
</resources>
<application-desc main-class="org.jnativehook.example.NativeHookDemo">
</application-desc>
</jnlp>

[kwhat]

Give 803e24d a try, I don't think it will fix anything but its how the code should have been written. I am out of ideas unless you have some test code to duplicate the issue.

[tinarm]

Thank you very much for the input, I will try the ref above. Unfortunately I'm home with a sick kid today, but I'll continue as soon I'm back in business again. I'll let you know the results.

A recap:

• OS X 10.9 and 10.10
• The issue only appears when the app doesn't have access to the accessibility feature
• The NPE happen about the same time the app requests access to the accessibility feature (system dialog appears asking for accessibility)
• My app works fine with JNativeHook 1.1.4, but not with 1.2+

[kwhat]

Assuming that I didn't make a mistake deploying this via JNLP, and it ONLY happens on OS X >= 10.9, the problem maybe related to this questionable piece of code. Try building libuiohook on OS X and see if you get an error. The USE_WEAK_IMPORT is disabled by default, try enabling that with configure --enable-weak-import and see if that changes anything. I don't know how C99 code would produce a java.lang.NullPointerException, but I have seen so many strange things come out of Apples black-box frameworks that I wouldn't be surprised if it did.

[tinarm]

I fetched the latest changes from JNativeHook master, and edited libuiohook/configure.ac to enable weak import. But unfortunately it didn't help.

(About the java.lang.NullPointerException; I use the java.lang.Thread.UncaughtExceptionHandler to pick up any uncaught stuff. Maybe that class translates exceptions to a Java class.)

[kwhat]

I still can't seem to duplicate using Thread.setDefaultUncaughtExceptionHandler and 10.7. Are you using GlobalScreen.getInstance().setEventDispatcher(...)? If you are, and your EventDispatcher implementation doesn't hand off the event to a new Thread, that exception could be originating in one of your event callback functions. In that situation, exceptions would be thrown up though the "JNativeHook Native Hook" thread.

For debugging, there is a branch called no_thread in both JNativeHook and libUIOHook. That branch moves the "JNativeHook Native Hook" thread out of C and into Java and may help you track down where the problem is popping up. You will need to checkout the JNativeHook no_thread branch first, and then checkout libUIOHook no_thread to the src/libuiohook folder.

[tinarm]

No, I'm not using a custom event dispatcher. The "no_thread" branch sounds interesting for debugging, I'll try that as soon as possible. :)

I'll also test your demo app in my environment.

[roberttyson]

I am having a similar problem with 1.2rc4 on OS.X 10.9. I running a local java application using java 1.8.0_25. Before the app gets accessibility permissions I get the exception listed below. Once I give the app permissions and restart it everything works just fine.

2014-12-11 14:06:33.168 ERROR [AWT-EventQueue-0]
App Problem checking accessibility
java.lang.NoClassDefFoundError: org/jnativehook/NativeHookException.(SLjava/lang/String;)V
at org.jnativehook.GlobalScreen.registerNativeHook(Native Method)
at App.checkAccessibilityAccess(AccessibilityAccess.java:56)
at App.init(App.java:124)
at App.lambda$0(App.java:86)
at App$$Lambda$21/1911728085.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
at java.awt.EventQueue.access$400(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:697)
at java.awt.EventQueue$3.run(EventQueue.java:691)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

[tinarm]

This should be fixed by this commit.

It has been applied to master after the RC4 release.

[kwhat]

No progress on this bug yet, although I did find a bug in the build system on OSX. The app starts for me with JNLP and does throw the exception if accessibility is disabled. It also throws a Exception in thread "JNativeHook Native Hook" java.lang.NullPointerException in the console somewhere before hook_thread.c:275 O_o. If accessibility is enabled, it starts and then promptly crashes deep within the JVM without much information about what happened. It seems to be crashing somewhere in the dispatch process. I am testing with 10.10 and Java 7. I'll bet you a beer this is caused by some undocumented auto-magical feature of one of the OS X frameworks that is altering pthread behavior in a POSIX breaking way.

[kwhat]

Well, the no_thead branch works just fine after apply your pull request to it... The problem is starting a pthread and attaching it to the JVM under OS X. I also noticed that the C frameworks (like CoreFoundation) also break C with things like LLVM closures ::cough cough:: "Blocks". Apple is getting really good at destroying standards.

[tinarm]

Thanks for all your work, I'll take a look at your findings and as soon as possible test the new master branch. :)

I'm sorry that I've not been able to put in any work on this the last few days, I've been really bussy with other stuff. But I'll soon get some time to test this out!

[tinarm]

I agree that OS X isn't always the smoothest system for development. And specifically with JNLP we've seen some strange stuff. And about that beer; if we ever meet I promise to buy you one no matter what, that's the least I could do. :)

[kwhat]

No problem, I have been working on some other stuff my self. I managed to merge that no_thread branch into the trunk for both projects so just pull and compile. I didn't want to make this particular change until 1.3 because I haven't done a huge amount of testing with it, but it seems like it's running smoothly and it simplifies a lot of the native code without breaking any of the Java API. Please do some testing on your end and let me know how things work out.

[tinarm]

I'm sure I'll get some time tomorrow (if all goes well I might have time today) for testing the new master.

[kwhat]

Hey just wanted to touch base and see if you had a chance to test this issue after the no_thread merge. If not, don't worry it's not a rush, but you should note that the build system was updated in the trunk today to make some adjustments for Apple. You will need to grab the trunk for JNITasks and replace the jar/JNITasks.jar file to build. Also note that gcc support for Apple has been dropped because the C frameworks depend on LLVM extensions like Apple Blocks. Things are currently building for me, but I have a limited test environment at home. I'll update the docs and provide a JNITasks binary as soon as I feel like I didn't miss anything ;)

[tinarm]

Hi and thanks for the info. I'm sorry that I haven't got the time yet to test it out, but it's the next thing on my todo list. A lot of other things showed up on my desk the last days that needed my attention.

[tinarm]

Alright; I've just tested the latest HEAD (dcbeb3a) on master, and it works great for me!
I'll save one of my christmas beers for you. ;)

[kwhat]

Awesome! Thanks and cheers! Happy holidays!