Skip to main content

Java application opening then immediately closing on OSX

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 ):


export JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

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:


/usr/libexec/java_home

You could make use of it, much like the hard-lined code snippet above, in scripts by executing something along the lines of:


export JAVA_HOME=`/usr/libexec/java_home`

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

Labels:
Location: Portland, OR, USA

Comments

Post a Comment

Popular posts from this blog

Kicking things off

My purpose here is to document various thoughts and findings as things come up, or come to mind.  All strictly technical, and kind of a development diary of sorts.  While ideally, others may find these things useful, my main intent is to have them here for my reference ;-) Still, I'll try to write them in tutorial fashion
Post a Comment
Read more

Add pre-compiled Elixir on OS X

So, I've been a big Erlang fan for a few years now, and then found out about Elixir :  what I would describe as kind of a Ruby -ish creamy frosting on top of Erlang . But I'll address more on both in future. Right now, I thought I'd just give a quick and dirty way to add Elixir , if you've already got Erlang installed (hint: check-out this Erlang Solutions link for a pre-compiled Erlang solution).  You can also use brew to install both , but I have found that with the simplicity of brew, you give up having the most current version of software.  In both cases. The pre-compiled zip for the most current version of  Elixir can be found here .  Unzipping reveals a folder containing everything you need.  For simplicity's sake, keeping everything pertaining to Elixir all within this folder makes the most sense.  By doing so, all that's needed is to position the folder, and then make links to all the executables in a directory already in our path.  Through t...
Post a Comment
Read more

Screen Scraping in Ruby with Watir and Nokogiri

I was given an interesting challenge to scrape some data from a specific site.  Not to write a completed, packaged solution, but rather just to scrape the data.  The rub being, the site uses Javascript paging, so one couldn't simply use something like Mechanize.  While a self-contained product would require inclusion of V8 (as the Javascript would need to be run and evaluated), to just scrape the data allows making use of whatever is easy and available.  Enter Watir . Watir allows "mechanized/automated" browser control.  Essentially, we can script a browser to go to pages, click links, fill out forms, and what have you.  It's mainstay is in testing, but it's also pretty damned handy in cases where we need some Javascript on a page processed... like in this case.  Keep in mind though, it is literally automating a browser, so you'll see your browser open and navigate to pages, etc. when the script runs.  But, there is also a headless browser opti...
Post a Comment
Read more