With JabRef, we experience a weird situation where some users get the following error when starting JabRef
We do not ship a JRE with our application and rely on that Java is installed on the machine of the users.
We have a long issue on GitHub about this particular error and despite all our efforts, it seems we cannot find the source of the issue. Especially, since none of the devs can reproduce it. Fortunately, one of the users who experiences this error was kind enough to provide all information about his machine:
$ java -version
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxr-xr-x 1 root wheel 74 Aug 14 12:09 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
1.8.0_161, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
1.8.0_121, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
$ echo $JDK_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
I asked this particular user to provide the INSTALL4J_LOG and so that we can compare the log-files of Install4J on my machine where it works and on the users machine where it fails.
My machine runs OS X 10.13.2 and the system of the user is OS X 10.12.6.
There are two main differences between them. The first difference is that when I invoke the JabRef launcher, it instantly tells me the order of places to search for Java:
2018-01-24 02:10:14.437 JavaApplicationStub[4846:345347] -[Launcher findJavaBundle:] [Line 479] search sequence (
EPATH,
Y,
"EJAVA_HOME",
"EJDK_HOME"
)
This is exactly the order we have configured in Install4J
On the users log-file this part is missing completely. However, it doesn't really matter, because the JRE/JDK is very rarely included in the $PATH variable. The next things to check are the default locations and this will find the JRE in Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin first.
Therefore, on my machine and on the users machine, JabRef will use this JRE and not any of additionally installed JDK's.
Now, there is the probably more important difference. On the machine of the user, it seems the JRE needs to be unpacked which does not happen for me:
2018-01-23 12:27:08.320 JavaApplicationStub[40695:1133965] -[Launcher findJavaBundle:] [Line 474] Running unpacker
2018-01-23 12:27:08.323 JavaApplicationStub[40695:1133965] +[Unpacker unpack:withProgress:] [Line 24] found ()
2018-01-23 12:27:08.323 JavaApplicationStub[40695:1133965] +[Unpacker unpack:withProgress:] [Line 24] found ()
After that, the logs look similar but when finally the JRE is invoked, it cannot be found on the user's machine and we get the error message
2018-01-23 12:27:08.328 JavaApplicationStub[40695:1133965] int launcher_main(int, char **) [Line 925] Could not load JRE from The bundle “Java SE 8” couldn’t be loaded because its executable couldn’t be located..: (
0 CoreFoundation 0x00007fff8ff882cb __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fffa4d9e48d objc_exception_throw + 48
2 CoreFoundation 0x00007fff90006c3d +[NSException raise:format:] + 205
3 JavaApplicationStub 0x0000000100008644 -[Launcher launch] + 468
4 JavaApplicationStub 0x0000000100008ef5 launcher_main + 645
5 JavaApplicationStub 0x0000000100009062 main + 34
6 JavaApplicationStub 0x0000000100001504 start + 52
)
Now, I'm not sure why unpacking is necessary and if it can be explained by the particular JRE or the different Mac OS versions.
In any way, I have asked the user to install the Oracle JRE 1.8.0_161 so that we both have the exact same Java and I'll report back if this solved the problem.
However, has someone a bright idea why the Install4J launcher crashes?
