1

We've got an application which we've recently added JavaFX to, and updated to the latest JRE, and now Jwrapper won't launch the application on Windows (MacOS and Linux are fine).

We've followed the instructions on this post http://www.jwrapper.com/blog/bundling-javafx-into-a-native-exe and changed our JWrapper config accordingly.

We are using JDK1.80_102 and JWrapper version: jwrapper-00044250826.jar. We are building via maven (we have a plugin that does this).

The application downloads, but will not launch. See the logs below:

+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!
Mark
  • 45
  • 1
  • 4

1 Answers1

0

NOTE: This is a workaround, not a fix for this issue.

If anyone else come across this problem, one workaround is to use the 32-bits Windows JRE.

As it can be noticed in the log, when JWrapper is starting the JNI launch, it will try the "server" JVM first (...\bin\server\jvm.dll), which is present in the 64-bits JRE.

And then, after it failed for some reason (JWrapper doesn't provide any useful information about it), JWrapper will try to load the "client" JVM (...\bin\client\jvm.dll).

The "client" JVM doesn't exist in the 64-bits JRE (and it's not there for ages, not sure why JWrapper is still trying to load it).

Now, if you use the 32-bits version, you should notice a change in the log:

++++++++++++++++++++++++++++++++++++++++++++++++
[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.

Now the situation is inverted, the "server" JVM is not found and the "client" is there (as expected).

JWrapper is still unable to load it though, and it still doesn't provide any useful information for why it can't be loaded.

The main difference now is that, even though JWrapper can't load the client JVM, it will try a legacy spawn instead, which worked well in my case.

Gilberto Olimpio
  • 681
  • 14
  • 23