Java 11 DLL is crashing... about jintellitype HOT 46 CLOSED

Yep working with @HopefullyICanChangeThatNameLaterOn we have not been able to get it to work on Java 9,10,11. Java 8 and below works fine.

from jintellitype.

I asked that question here:
https://stackoverflow.com/questions/56686375/java-backwards-compatibility-for-jni-libraries
Maybe it's easy to fix.

from jintellitype.

Yes, for JDK11 i'm getting a hard crash of java when calling method registerHotKey() (see windows log below - sorry that it is german). In JDK8 the same code runs without issue.
Used is the 64bit version of JIntellitype.dll (version 1.3.9).

Name der fehlerhaften Anwendung: javaw.exe, Version: 11.0.1.0, Zeitstempel: 0x5bb8a935
Name des fehlerhaften Moduls: JIntellitype.dll, Version: 0.0.0.0, Zeitstempel: 0x4b5c9033
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000001d4e
ID des fehlerhaften Prozesses: 0x21f4
Startzeit der fehlerhaften Anwendung: 0x01d4a4e32dbec2ca
Pfad der fehlerhaften Anwendung: C:\Program Files\Java\jdk-11.0.1\bin\javaw.exe
Pfad des fehlerhaften Moduls: D:<path>\JIntellitype.dll

from jintellitype.

Damn, something about JNI must have changed then. Because that is the only reason I could see getting a DLL crash. Has anyone tried it in JDK9 or JDK10? Just wondering if this was introduced with 11 or with Java Modulues Jigsaw in JDK9.

from jintellitype.

I wonder if I can try recompiling the C DLL with JDK11.

from jintellitype.

Has anyone tried it in JDK9 or JDK10? Just wondering if this was introduced with 11 or with Java Modulues Jigsaw in JDK9.

Same issue in JDK9.0.4.

Name der fehlerhaften Anwendung: java.exe, Version: 9.0.4.0, Zeitstempel: 0x5a39c930
Name des fehlerhaften Moduls: JIntellitype.dll, Version: 0.0.0.0, Zeitstempel: 0x4b5c9033
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000001d4e
ID des fehlerhaften Prozesses: 0x2254
Startzeit der fehlerhaften Anwendung: 0x01d4a52219d839ee
Pfad der fehlerhaften Anwendung: C:\jdk9\bin\java.exe
Pfad des fehlerhaften Moduls: D:<path>\JIntellitype.dll

from jintellitype.

Thanks for confirming. I had a feeling that would be the case.

from jintellitype.

I have definitely verified the issue however I am struggling to recompile the new one 64 bit. I remember years ago I was building the 32 bit DLL and someone else came along and compiled it for 64 bit and sent me the DLL. I am definitely no C++ expert either.

from jintellitype.

Taking a look in the strings of the DLL gives me following results:

So it seems that mingw has been used.
There seems to be a good guide here for getting all this done: http://capsis.cirad.fr/capsis/documentation/java-c_connectioncompleteexample

So i hope this is working by using the two mentioned lines from the guide:
D:\coligny\workspace\capsis4\ext\windows64>g++ -c -m64 simpleDLL.cpp
D:\coligny\workspace\capsis4\ext\windows64>g++ -shared -m64 -o simpleDLL.dll sim
pleDLL.o

from jintellitype.

You want to take a crack at it? You definitely want to use MinGW 64 as I know before when I compiled the 32 bit with BloodShed C++ i used MinGW32.

from jintellitype.

I'm also not an C++ expert but i can give it a short try on the weekend.

from jintellitype.

Much appreciated.

from jintellitype.

So I just played around and could compile all DLL but it is still producing the same error. So i guess we really need a C++ expert to continue further...

Name der fehlerhaften Anwendung: javaw.exe, Version: 11.0.1.0, Zeitstempel: 0x5bb8a935
Name des fehlerhaften Moduls: JIntellitype.dll, Version: 0.0.0.0, Zeitstempel: 0x5c39edc2
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000001bc2
ID des fehlerhaften Prozesses: 0x1a84
Startzeit der fehlerhaften Anwendung: 0x01d4aa7c1838e844
Pfad der fehlerhaften Anwendung: C:\Program Files\Java\jdk-11.0.1\bin\javaw.exe
Pfad des fehlerhaften Moduls: D:<path>\JIntellitype.dll
Berichtskennung: 15d45963-b987-454b-9043-ce7b51c2b8d6
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Commands used for compiling:
g++ -c -m64 JIntellitype.cpp -I"C:\Program Files\Java\jdk-11.0.1\include" -I"C:\Program Files\Java\jdk-11.0.1\include\win32"
g++ -c -m64 JIntellitypeHandler.cpp -I"C:\Program Files\Java\jdk-11.0.1\include" -I"C:\Program Files\Java\jdk-11.0.1\include\win32"
g++ -c -m64 JIntellitypeThread.cpp -I"C:\Program Files\Java\jdk-11.0.1\include" -I"C:\Program Files\Java\jdk-11.0.1\include\win32"
g++ -c -m64 StdAfx.cpp -I"C:\Program Files\Java\jdk-11.0.1\include" -I"C:\Program Files\Java\jdk-11.0.1\include\win32"

g++ -shared -m64 -o JIntellitype.dll JIntellitype.o JIntellitypeHandler.o JIntellitypeThread.o -I"C:\Program Files\Java\jdk-11.0.1\include" -I"C:\Program Files\Java\jdk-11.0.1\include\win32" -lgdi32 -static -static-libgcc -static-libstdc++

I also modified some files to get rid of compilation errors/warnings.
The change commited in file com_melloware_jintellitype_JIntellitype.h seems to be wrong. "jclass" seems to be right.
In JIntellitypeHandler.cpp: used "env->GetLongField" instead of int. Used "GetWindowLongPtrA" instead of "GetWindowLong".
Changed some int casts to to other things. I assume that we might have an issue here since 64bit ints are bigger than 32bit. Just as idea...
As I said: i'm not an C++ expert and my changes might not even make sense. Don't commit them on github :)

cpp.zip

from jintellitype.

Can you try and compile it with the latest .h file I checked in? I noticed that when I generated the H file with Java 11 it made one minor change from my original.

https://github.com/melloware/jintellitype/blob/master/src/main/cpp/com_melloware_jintellitype_JIntellitype.h

It changed a jclass method to jobject. Not sure if that is the difference?

I compile it with Java 11 using javac -h JIntellitype.java to generate the .h file so its interesting its generating it with jobject instead of jclass?

from jintellitype.

I'm still getting the same error if that's what your asking. I'm using the latest version that you just updated on here.

from jintellitype.

I try to build the DLL on my own (Win7 64 bit, Blodsheed 4.9.9.2).
There I recognized that there is a compile error.

In JIntellitype.cpp (line 145) I had to fix the function to let it fit to the definition in the com_melloware_jintellitype.h file (line 47).

in "com_melloware_jintellitype.h"
JNIEXPORT jboolean JNICALL Java_com_melloware_jintellitype_JIntellitype_isRunning
(JNIEnv *, jobject, jstring);

in "JIntellitype.cpp" OLD
JNIEXPORT jboolean JNICALL Java_com_melloware_jintellitype_JIntellitype_isRunning
(JNIEnv *env, jclass, jstring wndName)

in "JIntellitype.cpp" NEW
JNIEXPORT jboolean JNICALL Java_com_melloware_jintellitype_JIntellitype_isRunning
(JNIEnv *env, jobject, jstring wndName)

Maybe the h or cpp file is not updated in git?

After that change it is compileable.

from jintellitype.

@luecking You got it compiling, but does the new DLL then work in Java 9,10, or 11? if so please send me your new compiled DLL and Jintellitype.cpp file and I will add them to Git.

from jintellitype.

Only the compile works and only for 32bit.
I've not yet tested the whole queue with JNA. It's just a first step.
Could you cofirm the problem with jclass/jobject?

But I also do not have enough experience with C++ to convert it to 64bit.
I try to get it running, but it will take time.

from jintellitype.

The jclass/jobject may be true because if you look here: https://github.com/melloware/jintellitype/tree/master/src/main/cpp

You can see 5 months ago I regererted the .h file using Java 11 hoping that would solve our issues it did not.

from jintellitype.

I can confirm that I got it running with Java 11 (64 bit) on Windows 7 (64 bit), without making any changes. Just taking the latest jar from here and calling an explizit "setLibraryLocation"
I have now to verify where are other differences between Windows 8 (64 bit). Probably it is a too restrictive setting of the UserAccessControl, which forbids loading the dll. I really do not know yet.
And I will verify how it behaves on a Windows 10 (64 bit) system.

By the way, I found at https://github.com/kristian/system-hook a very clever way to automatically distinguish between 32/64bit. Maybe something you can add when loading the dll automatically?

from jintellitype.

wait so all you changed was just adding setLibraryLocation?

from jintellitype.

I just tried in windows 10 with JDK 11.0.1 by doing this and its still crashing...

JIntellitype.setLibraryLocation("C:\\jintellitype\\JIntellitype64.dll");

from jintellitype.

I've to test it in my other environments.
In my running example I used OpenJDK 11.0.2 (64bit) on Windows 7 (64bit) together with setLibraryLocation.

from jintellitype.

OK let me know I am also running OpenJDK 11.0.1.

from jintellitype.

Yeah, but I'm running on OpenJDK 11.0.2 ;-)
Maybe this is already a difference!?

from jintellitype.

Sorry to say. With Windows 8 (64bit) and OpenJDK 8, it runs.
With OpenJDK 11.0 it runs not, with OpenJDK 12.0 it also runs not.

On the other side, with OpenJDK 8 my copy to Clipboard function works only once and after that not anymore. So, also not a solution. I hope to get it tested with Windows 10 in the next days.

from jintellitype.

Yep that is what I am seeing. JDK8 is the only one that works for me and 9,10,11,12 all crash.

from jintellitype.

I did some more testing. The failure does not create the usual hs_err*.log dump file. Indeed, it occurs after registering a hotkey (so it's unlikely to be a JNI issue), but not on the main execution thread where I put a Thread.sleep(). The register call goes through, a print statement after it gets printed out, and then the VM simply crashes without an error dump. Does JIntellitype use any background thread that might not be correctly synchronized? Or maybe there is a conflict with the AWT/Swing windowing system which has its own UI thread(s)?

from jintellitype.

OK so I will be the first to admit I am a Java guy and not a C++ guy and when I wrote this years ago i had worked from a JNI example of something similar. There is a thread.

https://github.com/melloware/jintellitype/blob/master/src/main/cpp/JIntellitypeThread.cpp

If I remember I had to instantiate a Window so I can listen to the Keyboard and Intellitype events in the Windows Event loop and also it helps prevent two instances of the same app.

from jintellitype.

If I had to guess, I'd say that this external window is causing Java's AWT/Swing to malfunction. This is a known issue, for example, for opengl Java libs that simply won't work (reliably) if AWT code is touched within the same VM. The AWT windowing system simply cannot handle non-AWT windowing actions and seems in fact incompatible with it. The system-hook package seems to go down a cleaner route -- sadly it's not on maven central. One could try to verify that by removing all AWT/Swing code from the package....

from jintellitype.

What is strange though that its been working for years in Java 5,6,7,8 and now with 9,10,11 crashes. So it must have been introduced with 9 or my code has always been wrong and just happen to work. :)

from jintellitype.

Yes, unsupported use-case scenarios often look like that: they get developed as long as there is accidental support, and some day it stops working.

from jintellitype.

Of course, one could also simply put the DLL into a separate executable and replace the JNI bindings with a simple pipe to that executable. That is, if it's really a clash of VM/OS resources.

from jintellitype.

Seems the system-hook project suffers a similar issue: kristian/system-hook#17 and there seems to be no other way than to use a slave process to handle the low level OS stuff.

from jintellitype.

Apparently, it's possible to register hotkey without window resources: https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-registerhotkey

from jintellitype.

You are right his code is doing something almost exactly like mine creating and invisible window to listen to the HotKey and Intellitype commands.

https://github.com/kristian/system-hook/blob/master/src/main/native/windows/SystemHook.c#L328-L329

from jintellitype.

This works on Java 11, and you don't even need native code:

https://github.com/java-native-access/jna/blob/cc1acdac02e4d0dda93ba01bbe3a3435b8933dab/contrib/platform/test/com/sun/jna/platform/win32/User32Test.java#L126

Just a dependency on jna/jna-platform.

from jintellitype.

Whoah I have never heard of "com.sun.jna.platform.win32.WinDef" is that available in the JDK for all users? Theoretically we could change Jintellitype to use that if we could figure out a way to also listen to the Intellitype commands a well.

from jintellitype.

There is also a global keyboard hook which seems to get all keypress and releases, maybe even the stuff you need for intellitype.

https://github.com/java-native-access/jna/blob/master/contrib/w32keyhook/com/sun/jna/contrib/demo/KeyHook.java

And, no, it's not part of the JDK, it's a separate project. https://github.com/java-native-access/jna

from jintellitype.

That is a pretty amazing library from looking at it. Extremely ambitious!

from jintellitype.

@mellware: Playing with system-hook or native-hook, I recognized in some cases different behavior.
One point was that not all solutions really supported the "Windows key". And the other things was, that the behavior in case any button was pressed is different.
In JIntellitype after a button press, the assigned function will be called and nothing else.
In native-hook it fealt like that the pressed button was not really "finished", further activities bind to the button were processed.
Please check if you can see some similar behavior.

from jintellitype.

Yes I believe that is the case. I believe my DLL "eats" the windows signal basically letting Windows know we handled it. It doesn't then continue on and allow other apps to process it.

from jintellitype.

I just learned java and want to write a screenshot tool for work，emmmm，hope you can resolve it

from jintellitype.

It seems that Java 8u261 is causing similiar issues. The program that is using JIntellitype simply vanishes when global hotkeys are enabled. I found this in the event log:

Name der fehlerhaften Anwendung: java.exe, Version: 8.0.2610.12, Zeitstempel: 0x5eeb13ea
Name des fehlerhaften Moduls: JIntellitype.dll, Version: 0.0.0.0, Zeitstempel: 0x4b5c9033
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000001dff
ID des fehlerhaften Prozesses: 0x2890
Startzeit der fehlerhaften Anwendung: 0x01d65bfa6eb889a6
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe
Pfad des fehlerhaften Moduls: C:\path_to_program\JIntellitype.dll

from jintellitype.

Yep that looks like the same problems and symptons as I was seeing with Java11. They must have backported something to Java6_261 that causes this issue.

from jintellitype.

1.4.0 is now in Maven Central: https://repo1.maven.org/maven2/com/melloware/jintellitype/

from jintellitype.