Shutdown Hook problem when using JavaFX

[DavidTheExplorer]

Hello, I'm trying to consume events within a JavaFX program.
It works well, but I discovered that closing the program doesn't run the shutdown hook.
Here is my code(called during startup by the UI thread):

private static void setupJNativeHook()
{
    try
    {
        GlobalScreen.setEventDispatcher(new VoidDispatchService());
        GlobalScreen.registerNativeHook();
    }
    catch(NativeHookException exception)
    {
        throw new IllegalStateException("Failed to enable JNativeHook", exception);
    }

    Runtime.getRuntime().addShutdownHook(new Thread(() ->
    {
        try
        {
            GlobalScreen.unregisterNativeHook();
        }
        catch(NativeHookException exception)
        {
            throw new IllegalStateException("Failed to unregister JNativeHook", exception);
        }
    }));
}

[kwhat]

You will need to hand-off the call to GlobalScreen.unregisterNativeHook(); event to a different thread.

[DavidTheExplorer]

You will need to hand-off the call to GlobalScreen.unregisterNativeHook(); event to a different thread.

I probably did this wrong... same result :/

Runtime.getRuntime().addShutdownHook(new Thread(() ->
{
    CompletableFuture.runAsync(() ->
    {
        try
        {
            GlobalScreen.unregisterNativeHook();
        }
        catch(NativeHookException exception)
        {
            throw new IllegalStateException("Failed to unregister JNativeHook", exception);
        }
    }).join();
}));

[kwhat]

Windows or macOS?

[DavidTheExplorer]

Windows 10

[kwhat]

So looking at the backing src, https://github.com/kwhat/libuiohook/blob/1.2/demo/demo_hook.c#L69 you should be able to call from the same thread, maybe try that? There is also some logging on the stop hook that you should see in the logger output (https://github.com/kwhat/libuiohook/blob/1.2/src/windows/input_hook.c#L723) which may give us some insight into why it isn't stopping.

I haven't really tested this library with JavaFX, it should work in theory but I haven't really put a whole lot of effort into it... what exactly are you using this for? I am asking because I suspect most people using this library should really be using some form of HID instead.

[DavidTheExplorer]

you should be able to call from the same thread, maybe try that?

I'm not sure what you mean here, which thread?

There is also some logging on the stop hook that you should see in the logger output which may give us some insight into why it isn't stopping.

How can I enable that logging? Currently I don't see anything printed to console.

I haven't really tested this library with JavaFX, it should work in theory but I haven't really put a whole lot of effort into it... what exactly are you using this for? I am asking because I suspect most people using this library should really be using some form of HID instead.

I prefer not to discuss my project in public, we can talk on discord if you want.
In general, I don't see why would a UI library interrupt your library, but I'm very far from low level stuff so my opinion isn't really valuable.
JavaFX is just a wrapper(or entrypoint) for my domain code, which works flawlessly when ran on the normal main thread.

[kwhat]

you should be able to call from the same thread, maybe try that?

Eh I just read the documentation, I have no idea what Java FX is doing on this thread... maybe you can use Platform.runLater() from within the callback.

How can I enable that logging? Currently I don't see anything printed to console.
https://github.com/kwhat/jnativehook/blob/2.2/doc/ConsoleOutput.md

In general, I don't see why would a UI library interrupt your library, but I'm very far from low level stuff so my opinion isn't really valuable.

All UI's are single threaded. Java / Java FX all run the UI events on a single thread. The low level hook has a different dispatcher thread for its events, or it can use Swing's event dispatcher to send the events out.

When you setup to consume events with this library via the void dispatcher, you are running on the OS's dispatch thread. Somewhere in this mess, you have introduced a thread safety issue and its difficult to figure out where because we are debugging though Java > C > OS and all the threads in-between. I don't really have a lot of experience with Java FX so I have no idea how the shutdown handler is operating or if unrestringing the hook is possible from that context.

The reason I am asking about what you are trying to do is because this library is basically dead due to issues on the Linux/Unix side of things. The only conceivable way forward is to use HID to accomplish what this library provided. That will get you most of the functionality with the exception of absolute mouse positioning and key char's produced for key typed events. There are several java projects that support HID at this point, both though the native interface and via pure java.

[DavidTheExplorer]

@kwhat Good morning :] I have a new finding: I finally noticed that the shutdown hook does run, but only when I use IntelliJ's shutdown or rerun buttons - If I click the red X in the GUI, the process stays open after the window has closed.

maybe you can use Platform.runLater() from within the callback.

Doesn't work, even calling Runtime#addShutdownHook within Platform#runLater didn't help.
I had tried more combinations before I opened this issue, nothing worked.

When you setup to consume events with this library via the void dispatcher, you are running on the OS's dispatch thread. Somewhere in this mess, you have introduced a thread safety issue and its difficult to figure out where because we are debugging though Java > C > OS and all the threads in-between. I don't really have a lot of experience with Java FX so I have no idea how the shutdown handler is operating or if unrestringing the hook is possible from that context.

Thanks for the explanation. It helped me realize the whole picture, so it's absolutely okay if you don't want to do hard work just for one use case(JavaFX).

The reason I am asking about what you are trying to do is because this library is basically dead due to issues on the Linux/Unix side of things. The only conceivable way forward is to use HID to accomplish what this library provided. That will get you most of the functionality with the exception of absolute mouse positioning and key char's produced for key typed events. There are several java projects that support HID at this point, both though the native interface and via pure java.

I read about the term in Wikipedia and became even more confused, so I'm just gonna say what my project does: It uses your library to listen for keyboard events, then disables them in order to allow java.awt.Robot to take action based on the key pressed.
JavaFX is used to allow the end user to customize this.
If I switch to Swing, do you think the problem would still persist?

Lastly... I'm sorry to hear that this project is considered dead, I had no idea due to the star amount.
You have done a great job for Windows and I'm going to use it until it ever breaks.

[kwhat]

HID is an interface for things like keyboards and mice; Human Input Device(s). Most of the libraries out there like libusb/hidapi provide a nice interface for talking to these devices which is more or less the correct way to do what you probably want to do. The major difference between this library and HID interfaces is that mouse movement is reported relativity like x: -1, y: 1 instead of some resolution based approach that this library uses where you would get something like x: 127, y: 1012. The keyboard input is very similar to this library, you just don't get key typed events which deliver the language appropriate output for something like shift + a gives a capital letter A. In theory, you should be able to consume events using this interface, I was able to on Linux without to much trouble using libevdev.

I wanted this library to make input as close to what Java provided out of the box but without the window focus requirement. There were plans in my head to more closely integrate with Swing and make it feel more like it was part of the Java ecosystem but I never had the time to get there. The reason the library is kind of dead is because X11 is slowly being replaced by Wayland on Linux/Unix and it does not support passively grabbing events like Windows and macOS do. It only allows you to take full control of the input, or use something like HID. Since there are already a ton of HID libraries out there, there is no point in rewriting this one to do the same thing so I have basically stopped development on this project and started working on other things, some of which pay me in real money 😂

[DavidTheExplorer]

HID is an interface for things like keyboards and mice; Human Input Device(s). Most of the libraries out there like libusb/hidapi provide a nice interface for talking to these devices which is more or less the correct way to do what you probably want to do. The major difference between this library and HID interfaces is that mouse movement is reported relativity like x: -1, y: 1 instead of some resolution based approach that this library uses where you would get something like x: 127, y: 1012. The keyboard input is very similar to this library, you just don't get key typed events which deliver the language appropriate output for something like shift + a gives a capital letter A. In theory, you should be able to consume events using this interface, I was able to on Linux without to much trouble using libevdev.

I checked the first library you mentioned, it's written in C so I can't do anything with it.
I tried to search HID libraries in Java and found one candidate, but its examples are obscure(very low level) and I couldn't find any references to listening or consuming keyboard events.
What would you do if you were me? The only option seems to be resorting to making my project CLI, but that would suck.

I wanted this library to make input as close to what Java provided out of the box but without the window focus requirement. There were plans in my head to more closely integrate with Swing and make it feel more like it was part of the Java ecosystem but I never had the time to get there. The reason the library is kind of dead is because X11 is slowly being replaced by Wayland on Linux/Unix and it does not support passively grabbing events like Windows and macOS do. It only allows you to take full control of the input, or use something like HID. Since there are already a ton of HID libraries out there, there is no point in rewriting this one to do the same thing so I have basically stopped development on this project and started working on other things, some of which pay me in real money 😂

Fair enough amigo, but I think you should write something about this in the README to prevent future issues.