JWrapper mit JavaFX startet nicht unter Windows

Question

Wir haben eine Anwendung, die wir vor kurzem JavaFX hinzugefügt und auf die neueste JRE aktualisiert haben, und jetzt wird Jwrapper die Anwendung nicht unter Windows starten (MacOS und Linux sind in Ordnung)).

Wir haben die Anweisungen in diesem Beitrag http://www.jwrapper.com/blog/bundling-javafx-into-a-native-exe befolgt und unsere JWrapper-Konfiguration entsprechend geändert.

Wir verwenden JDK1.80_102 und JWrapper Version: jwrapper-00044250826.jar. Wir bauen via Maven (wir haben ein Plugin, das das macht).

Die Anwendung wird heruntergeladen, aber nicht gestartet. Siehe die Protokolle unter:

+0  ----- Starting Launcher ----- 
+0  [Launcher]  Arg[0]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\APPNAME (UAT).exe 
+0  [Launcher]  Arg[1]=-cp 
+0  [Launcher]  Arg[2]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\jarname-all-3012-SNAPSHOT.jar;C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\jwrapper_utils.jar 
+0  [Launcher]  Arg[3]=-Xms256m 
+0  [Launcher]  Arg[4]=-Xmx1024m 
+0  [Launcher]  Arg[5]=-Duser.groovyServer=groovy.server.url.com 
+0  [Launcher]  Arg[6]=-DcurrentEnvironment=UAT 
+0  [Launcher]  Arg[7]=-DreqServerVersion=2016-09-08:1.0-0 
+0  [Launcher]  Arg[8]=-DprojectVersion=3012-SNAPSHOT 
+0  [Launcher]  Arg[9]=-DstartBanner=o3gui/images/app_banner.gif 
+0  [Launcher]  Arg[10]=-Dswing.aatext=true 
+0  [Launcher]  Arg[11]=-Dapple.laf.useScreenMenuBar=true 
+0  [Launcher]  Arg[12]=-Dcom.apple.mrj.application.apple.menu.about.name=APPNAME 
+0  [Launcher]  Arg[13]=3 
+0  [Launcher]  Arg[14]=-Djavafx.macosx.embedded=true 
+0  [Launcher]  Arg[15]=jwrapper.JWrapper 
+0  [Launcher]  Arg[16]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\JWLaunchProperties-1473288163056-24 
+15  [Launcher] Found tail marker 
+0  [Launcher] App Name = APPNAME (UAT) 
+0  [Launcher] App Version = 
+0  [Launcher] JRE Version = 
+0  [Launcher] GU Version = 
+0  [Launcher] Min Splash MS = 850 
+0  [Launcher] Signature Public Key = 
+0  [Launcher] Can Override Splash = 0 
+0  [Launcher] Install Type = perm_user 
+0  [Launcher] Silent Parameter = 
+0  [Launcher] Update URL = 8 
+0  [Launcher] ExePath is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\APPNAME (UAT).exe 
+0  [Launcher] Master dir from exe path is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT) 
+0  [Launcher] Master folder is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT) 
+0  [Launcher] Located existing bin JRE runtime = C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete 
+0  [Launcher] JRE path is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete 
+0  [JNILaunch] Bin folder is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin 
+0  File exists: C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\server\jvm.dll 
+0  [JNILaunch] Trying to load library C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\server\jvm.dll [exists=1] 
+1  [JNILaunch] Unable to load library. Will attempt fallback. 
+0  [JNILaunch] Trying to load library C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\client\jvm.dll [exists=0] 
+0  [JNILaunch] Unable to load second library. 
+0  [JNILaunch] [ERROR] Unable to load JRE library! 

Answer 1

HINWEIS: Dies ist ein Problem zu umgehen, nicht eine Lösung für dieses Problem.

Wenn jemand über dieses Problem anders kommen, ein Abhilfe ist die 32-Bit-Windows- JRE zu verwenden.

Wie im Protokoll bemerkt werden kann, wenn JWrapper den JNI-Start startet, versucht es zuerst die "Server" -JVM (...\bin\server\jvm.dll), die in der 64-Bit-JRE vorhanden ist.

Und dann, nachdem es aus irgendeinem Grund fehlgeschlagen ist (JWrapper liefert keine nützlichen Informationen darüber), wird JWrapper versuchen, die "Client" JVM (...\bin\client\jvm.dll) zu laden.

Die "Client" -JVM existiert nicht in der 64-Bit-JRE (und sie ist seit Ewigkeiten nicht da, nicht sicher, warum JWrapper noch versucht, sie zu laden).

Nun, wenn Sie die 32-Bit Version verwenden, sollten Sie eine Änderung im Protokoll fest:

++++++++++++++++++++++++++++++++++++++++++++++++ 
[JNILaunch] Bin folder is C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin 
[JNILaunch] Trying to load library C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\server\jvm.dll [exists=0] 
[JNILaunch] Unable to load library. Will attempt fallback. 
File exists: C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\client\jvm.dll 
[JNILaunch] Trying to load library C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\client\jvm.dll [exists=1] 
[JNILaunch] Unable to load second library. 
[JNILaunch] [ERROR] Unable to load JRE library! 
[Extractor] Return code for JNI launch was 1 
------------------------------------------------ 
--- End: JNI Launch 

------------------------------------------------ 
[Extractor] JNI launch failed. Attempting legacy spawn instead 
[Extractor] Attempting spawn launch 
++++++++++++++++++++++++++++++++++++++++++++++++ 
+++ Start: Spawn launch 

++++++++++++++++++++++++++++++++++++++++++++++++ 
[Utils] Closing logging file. 

Jetzt ist die Situation umgekehrt wird, wird der „Server“ JVM nicht gefunden und die " Client "ist da (wie erwartet).

JWrapper ist immer noch nicht in der Lage, es zu laden, und es gibt immer noch keine nützliche Information, warum es nicht geladen werden kann.

Der Hauptunterschied ist jetzt, dass, obwohl JWrapper die Client-JVM nicht laden kann, stattdessen ein Legacy-Spawn versuchen wird, was in meinem Fall gut funktionierte.