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

Install current SBCL on OS X

You must have Command Line Tools installed. If you don't , this tutorial is not for you. Google: installation of XCode and Command Line Tools. Normally, I use brew to install things (when it offers a solution), but in this case the keg version was a couple minor version's off. And, there had been sufficient addition's that motivated me to want the current release. So, building from source was the path of least resistance. First, what not to do : The note's caution against using OS X's Terminal , as their make.sh script pukes a shit-ton of text during the build, and according to them, it can slow the build. I did not experience an issue with this, compared to other builds I've done in the past.   BUT , they also say build can be accomplished with other LISP's installed (you must have a lisp installed prior to building). OMFG , unless you want to wait a month of Sunday's, my experience building with CLISP was slower than the Molasses in January.  D
Post a Comment
Read more

React Simplicity

This is just a quick intro to React to show how easy it is on a very basic level. React is often compared to Angular, but the two are very different: Angular is more of a framework , whereas React is more of a library . So, with React, we can make Components, and in so doing, we can intersperse plain Javascript to instill behavior. This article is not showing (or using) best practices, or a recommended structure. It's purpose is only to show how easy the basic mechanics of React are. Let's grab the getting started cli from React's page npm install -g create-react-app create-react-app my-app cd my-app npm start After this is done, and you have the project displayed in your browser, let's experiment. A boiler-plate header we can use for each new class can be as simple as: /src/Foo.js import React, { Component } from 'react'; class Foo extends Component { render(){ return(); } } export default Foo; So, all that we need to change to get st
Post a Comment
Read more

Dead Simple React.js with Meteor

I spent a little time exploring the patterns involved in using React.js with Meteor. It's incredibly easy, it turns out. I'll show some examples here. The setup: meteor add kadira:flow-router npm install react react-dom react-mounter npm install react-addons-pure-render-mixin meteor add react-meteor-data Then of course remove all blaze related meteor packages. Ok, Some basic component patterns: Let's create one that accepts a single argument: Hello.jsx import React from 'react'; export const Hello = ({name}) => ( <div>Hello, {name}</div> ); That's all there is to it. Now, let's see a pattern for a component that takes two arguments. We can see that to add further arguments, we can just tack them on after the first two: TwoArgs.jsx import React from 'react'; export const TwoArgs = ({one, two}) => ( <div> <h2>TwoArgs!</h2> <h3>One is: {one}</h3> <h3>Two is: {two}&
Post a Comment
Read more