foigus' Notes

Mostly OS X Admin Related

Managing Java 7 and 8 Updates

Controlling your Caffeination Level
As part of improving software deployment at my organization, I tackled managing the Java 7 and 8 updater.  There’s a lack of Mac-based examples for this process (many thanks to Tim Sutton for his posts here and here, JAMF Nation-ites for this post, and Grivet-Tools for this post), so this is my contribution. The configuration file format for Java 7 is documented here and for Java 8 is documented here.  There are a pair of files:

  • deployment.config: Located at /Library/Application Support/Oracle/Java/Deployment/deployment.config, this file tells Java where to find the file (discussed below) and whether or not the file is mandatory.  If the file is mandatory and cannot be found, no Java software will be allowed to run.
  • A file listing various Java settings and optionally locking those settings.  Note that due to Safari sandboxing restrictions, must be located under /Library/Application Support in order for the Java plugin running inside Safari to access it (unless the Java plugin is running in Unsafe Mode).  A huge thanks to Michael Lynn (who goes by the IRC nickname “frogor” in the discussion about this restriction) for assistance with determining this requirement.

My deployment.config and files are below. First, deployment.config:

  • #deployment.config is a comment, and thus ignored
  • deployment.system.config details where the file can be found
  • deployment.system.config.mandatory=true tells Java the file is required.  If isn’t available Java code will not be executed

And then
  • is a comment, and thus ignored
  • deployment.macosx.check.update=false causes Java to not check for updates when the Java browser plugin runs.  However note the LaunchAgent-based background updater still checks for updates (we’ll handle that later)
  • deployment.macosx.check.update.locked prevents changing the deployment.macosx.check.update setting
  • deployment.expiration.check.enabled=false tells Java to not check to see if the current version of Java is expired.  Note Java has two expiration dates–one expiration date is the date of the next planned release (currently quarterly) if the computer can reach the Internet, while the second expiration date is 30 days after the next planned release date.  For example expiration dates, see the “Java Expiration Date” sections of the Java 8 Release Highlights
  • deployment.expiration.check.enabled.locked prevents changes to the deployment.expiration.check.enabled setting
  • sets the default Java security level to medium, but note the security level “medium” only exists with Java versions earlier than Java 8u20 (where the default security level was changed to “high”).  More details about Java security levels are located in the “Security levels in the Java Control Panel” section of this Oracle support page
  • prevents changes to the setting

But wait, there’s more!
In addition to the expiration and update checks that occur when running a Java applet in a browser, there also is an LaunchAgent-invoked background Java updater (the LaunchAgent job is located at /Library/LaunchAgents/ that will periodically check for Java updates and prompt for an update if one is available.  Unfortunately this prompt is shown to users who cannot actually install the Java update.  This automatic update check can be disabled with the following:

sudo defaults write /Library/Preferences/ JavaAutoUpdateEnabled -bool false

It’s very tempting to try to set this preference via a management system, however I did not have success with any of the following methods:

It appears the preference must literally be set in /Library/Preferences/ or it’s ignored.  Thankfully it’s easy to check to see whether this preference is set properly by setting the Java plugin to run in debug mode and then invoke the updater by hand:


/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java\\ Updater -bgcheck
2015-02-18 21:50:26.053 Java Updater[886:21122] Java Update Check is disabled

The Hits Just Keep on Coming
While testing this article, another settings file kept appearing at ~/Library/Preferences/ This file has very interesting looking keys:

$ defaults read /Users/admin/Library/Preferences/
 "/com/oracle/javadeployment/" = {
 "deployment.expiration.check.enabled" = false;
 "deployment.macosx.check.update" = false;
 "deployment.modified.timestamp" = 1424322701333;
 "" = MEDIUM;
 "deployment.version" = "7.21";

A simple way to set these preferences? Alas, no. It appears that Java treats this file as a cache, generated from Once I started testing whether just was enough to manage these settings, I discovered when I ran the Java plugin it reacted by wiping out most of the preferences in this file. There is one exception I could find. It appears that deployment.expiration.check.enabled is consulted from this file first, before  I noticed this because of the following scenario:

  • Install proper and deployment.config files
  • Install Java
  • Set the computer’s clock forward six months (thus Java was months beyond both expiration dates of the plugin)
  • Run the Java plugin in Safari
  • Be prompted the Java plugin had expired
  • Quit Safari
  • Run the Java plugin in Safari again
  • See no prompt the Java plugin had expired

This scenario does react to the initial setting of deployment.expiration.check.enabled in, however it will be subsequently overwritten by the setting in  This behavior is possibly part of the “native cache” Oracle mentions in this statement regarding deployment.expiration.check.enabled:

Note: To ensure that the expiration check is disabled, use the -userConfig deployment.expiration.check.enabled false option with the javaws command. If this property is changed in the file, open the Java Control Panel before starting an application to ensure that the native cache is synchronized with the file. Otherwise, the change might be ignored the first time an application is started.

Amusingly deployment.expiration.check.enabled can be handled properly via a Profile, however it should also be set in

After all of this, if the following is done:

  • Set settings via deployment.config and
  • Disable the background updater by writing a preference to /Library/Preferences/
  • Disable plugin expiration in (via a Profile or equivalent method)

Java should function even past expiration, however:

The easiest way to test all of the above is to download and install an out-of-date version of Java (so the security and expiration prompts will appear) and test these settings.  Note testing how Java 8 reacts to being expired is more difficult since the lowest security level (“high”) requires signed Java applets and successful validation of those signatures, thus it’s not possible to move the computer’s clock forward six months and have those signatures successfully validate.  In this case, make sure to test against a version of Java 8 that is old enough to be past the “secondary [expiration] mechanism” per the release notes.

2 responses to “Managing Java 7 and 8 Updates

  1. BP March 29, 2015 at 2:35 am

    Hey Patrick,

    I installed Java 8u11 and 8u40b27 on a clean install of 10.9.5 with no other changes made and I do not see /Library/Preferences/ ever get created. I tried running manually clicking the Check update button and did not see the file created. I did see ~/Library/Preferences/, but that did not have an entry for JavaAutoUpdateEnabled.

    I did create the file manually and noticed that setting it true or false does in fact control the “Check update” setting as you mentioned. My question is what exactly causes /Library/Preferences/ to be created?

    The only file I can find that’s called is located inside the Java Applet container that’s located in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/ but that’s just a LaunchAgent.


    • foigus March 30, 2015 at 1:05 am

      Since the Java updater is a faceless background process, there seems to be no visible (nor discoverable) way to set it. I think it could be considered a hidden setting.

      As for how I found it, I’m pretty sure I worked off of Tim Sutton’s mention here. The earliest mention I can find is on JAMF Nation from September 12, 2013.


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

%d bloggers like this: