When using this library to monitor events coming from a barcode scanner (which simulates keyboard keystrokes) it was found that events were delivered in the wrong order when there was high CPU load. This is because the use of a thread pool (Executors.newCachedThreadPool) to deliver each event means that delivery order is subject to when threads get run, which is not guaranteed by the JVM.
I have submitted the following pull request to change the "globalListener" to use a single thread for event delivery, which resolves the problem for the case I was dealing with. You may prefer to make wider modifications to enable in-order event delivery for "eventListeners" as well.
See: #2
When using this library to monitor events coming from a barcode scanner (which simulates keyboard keystrokes) it was found that events were delivered in the wrong order when there was high CPU load. This is because the use of a thread pool (Executors.newCachedThreadPool) to deliver each event means that delivery order is subject to when threads get run, which is not guaranteed by the JVM.
I have submitted the following pull request to change the "globalListener" to use a single thread for event delivery, which resolves the problem for the case I was dealing with. You may prefer to make wider modifications to enable in-order event delivery for "eventListeners" as well.
See: #2