I have had several occasion’s where Java apps would open, and then immediately close. Often, I don’t have the time to dig into the reason, as they aren’t crucial. So, I just move on. Recently, I was maddened by this happening to an application ( see other blog post on Kindle Previewer ) I really needed to use, so I had to get into the trench. After cracking open the app, and rooting through the various files, I did some spot-checks of the java version used to build the jars ( 2 bytes at offsets 6 & 7 ), as well as had a look at the info.plist, which had the JVMVersion key set at 1.5+.
Since Oracle took over Java, Apple has essentially abandoned it to them, and hasn’t done an update I think since version 6. All of Apple’s Tooling for Java stops with JVMVersion key’s of 6* and 6+. The short answer to all this is, if something was built using Apple’s AppBundler tools, and you have updated Java on your Mac to 7 or above, you’re probably SOL to get the app to work. The symptom is the app opening, and immediately closing.
You might think you could simply open info.plist, and change JVMVersion’s value to 7*, 7+, or maybe 8*, or 8+.. but you’d be wrong. One main factor that causes this is the location’s of Java have changed from where Apple had it, and where Oracle now installs it. Apple’s software of course looks for things where Apple expects them to be.
There are a few things you can do. Perhaps the simplest is to try setting:
version key’s value to 1.6 (NOT 1.6+) in info.plist ( within the contents/macos folder of the app ).
A sure fix is to change the launcher script ( located inside the “contents” of the app, within the MACOS directory ), and add the following line at the top of the file, just under the “shebang”: ( #!/bin/sh ):
The other is making use of java_home, a wonderful little tool that gives the Java Home location of the current JDK on stdout. It’s located:
You could make use of it, much like the hard-lined code snippet above, in scripts by executing something along the lines of:
This command has some options that are well worth having a look at.. this is a pretty handy little tool.
As an aside, another way of determining the version of Java that built a Jar is via the command-line’s file command. I don’t know if it’s 100%, but it should give good results. First crack open the jar:
$ jar xf Wambamdoodle.jar
And then use file on one of the classes from within the Jar:
$ file ./org/wamzo/wambamdoodle/Apprehender.class
It will return something along the lines of:
./org/wamzo/wambamdoodle/Aprehender.class: compiled Java class data, version 50
The class version’s major number corresponds to the following Java JDK versions:
- 46 = Java 1.2
- 47 = Java 1.3
- 48 = Java 1.4
- 49 = Java 5
- 50 = Java 6
- 51 = Java 7
- 52 = Java 8