Installer quit unexpectedly… root cause missing JavaLaunching.framework

Error logs indicate the system needs Java for the package installer to work properly.  As verified and documented below, it does not; it only needs a “framework folder” containing some reference information and will work just fine without a JRE, JVM, JDK, or any other part of Java.

This applies to (ie., verified on) 2013-03-31:  OS X Mountain Lion 10.8.3  
Given the age/history of the Installer utility, this issue probably applies to many other versions of OS X.

Attempts to install anything from a *.pkg results in “Installer quit unexpectedly.” error message.

Below is a snippet taken from multiple error logs resulting from trying to install different packages (two 3rd party apps, two Apple developer downloads, one OS X update, and one Oracle Java update).  All six pkg installations failed with error logs containing these same lines.

The problem… a few weeks ago I scrubbed the system of all traces of Java that I could find.  In light of all the recent Java exploit news, I wanted to test how complicated it would be to completely purge Java from the system; and I wanted to see if doing so would bring any unexpected consequences.  Well, removing all traces is complicated (and difficult to verify with certainty).  Although everything on the system continued to work fine, at first, there are unexpected dependencies… such as Apple referencing a Java Framework within their package installer.

Given the amount of “stuff” Apple OS X inherited from Sun Solaris over the years, this shouldn’t come as too big a surprise.  Sun used to regularly hard code Java Library dependencies into products which didn’t actually need them.  While the text of the error messages are different (but not by much), this is the exact behavior encountered installing certain Sun applications from the command line on headless servers… i.e.., the server had absolutely no reason to load a graphical environment, but the software installer was hard coded to look for the Java GUI packages.  For environments where security policies forbid unnecessary packages, we’d isolate the server, load the extra packages, complete the installation, and the remove the unnecessary packages… after the initial install/config was worked out, the organization would use DR processes to build new instances (eliminating the need to keep fiddling with those GUI packages).

ByTheWay, command line “Installer -vers” outputs “… v. 1.5.0 Copywright (c) 1999-2006 … ” That does match up with the time frame when code was being merged into OS X 10.4 from Solaris 10.

The fix… well, four of the above package installation attempts were attempts at fixing.  This is why hard coding dependencies is a bad idea; attempting to install a package that would solve the problem requires the referenced package, and fails.  After some research (and documentation of activity thus far), I tried another command line

         sudo installer -pkg /Volumes/OS\ X\ 10.8.3\ Update\ Combo/OSXUpdCombo10.8.3.pkg -target /

oops… got ahead of myself there.  That one may have been like swatting flies with a canon and I’d intended to try various command line options on the java packages first.  It’s done and requesting system restart now.  Didn’t matter, it didn’t solve the problem.  The framework was not restored and normal package installations are still failing.

Next I tried some other command line combinations and also tried extracting the packages to see if the frameworks could be manually located.  No joy with either approach.

Running out of options, but before I tried any of the operating system recovery / re-installation choices, I’ll try restoring the framework from TimeMachine.

Looking thru my backups, I found \System\Library\PrivateFrameworks\JavaLaunching.framework (and \JavaApplicationLauncher.framework) from a few weeks ago and restored the folder to it’s original location.

Result… restoring just 375KB of framework folders fixed the problem and the OS X package installer is working again.  It was not necessary to restore/install a JRE or JVM or any other part of Java.  It just needed required folder containing references to a Java framework.  Installer doesn’t need Java and it doesn’t use Java, but it was hard coded to require the presense of a symbolic reference.


Moral of the story…

  • Java – annoying.
  • hard coding artificial dependencies – shouldn’t be allowed to escape unit testing let alone make it into GA production release software.
  • backups which work and provide options for partial restores – everyone should have them.
  • Even simple steps for hardening a consumer operating system quickly become complicated, but can usually be resolved without to much fuss.
  • Code templates with a lot of “# Includes” may be convenient for developers but often
    1. present a headache for users – by creating required dependencies which should have been optional.
    2. introduce vulnerabilities – by requiring components which aren’t necessary in the target deployment environment.
    3. present long term maintenance problems – by making an entire application dependent on something which should have been an optional feature.
The problem report includes these lines:
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
  Library not loaded: /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching
  Referenced from: /System/Library/CoreServices/
  Reason: image not found
Binary Images:
       #x######### – #x######### (6.0 – 614) <3E180768-4C29-3B0D-A47D-F4A23760F824> /System/Library/CoreServices/
       #x######### – #x######### (1.0.5 – 30) <5ECA4744-FFA8-3CF0-BC20-3B2AD16AD93C> /System/Library/PrivateFrameworks/GraphKit.framework/Versions/A/GraphKit
       #x######### – #x######### (6.0 – 55024.4) <FCF87CA0-CDC1-3F7C-AADA-2AC3FE4E97BD> /System/Library/Frameworks/SecurityInterface.framework/Versions/A/SecurityInterface
    #x######### – #x######### dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld

3 thoughts on “Installer quit unexpectedly… root cause missing JavaLaunching.framework

  1. Just wanted to say thank you!
    Restored the two folders from Time Machine backup and all is good in the world again.

    I had done the same thing you did and got rid of anything JAVA related on Lion.
    This was after I updated Flash and Adobe threw in an 150MB add on of Lightroom 5 with no option to decline, and no way to cancel the update in progress.

    I just didn’t want all the added bloat or vulnerabilities, plus it’s just down right annoying that vendors like Adobe to just shove their crap down our throats without even asking. Java is just as bad in this practice.

    This all started after I got a new (used) iMac running OSX 10.7 Lion and migrated a C2D MBP running OSX 10.5 over.

    I had been using FireFox 17 with Silverlight to watch NetFlix, then upgraded to FF 21, which of course Mozilla saw in their wisdom to to disable the version of Silverlight I had and broke a few plugins too.

    I had even gone as far as grabbing the 1.3GB update ( to “fix” the issue, but it itself requires java to be working. Gotta love dependency hell *sigh*.


  2. thanks so much sir !

    i had the same problem on my macbook for a year because of the same wish to get rid of every last piece of java. but i didn’t find any solutions until now.

    good job.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s