jre_update_check_bug_report

Synopsis:

"Check for Updates Automatically" checkbox does not disable update checks on OS X.


Full OS version:

OS X 10.7.5, OS X 10.8.2


Development Kit or Runtime version:

java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)

(Note: Update 13 is used to verify that it really does find an updated version and prompts. Of course, Update 15 is the latest at this time and so it will not prompt for a new version as one does not yet exist.

I can, however, use the JPI_PLUGIN2_DEBUG environment variable to see that Update 15 is in fact doing an update check).


Description:

There is a checkbox in the Java control panel. to enable/disable checking for updates automatically. It does not actually control any behaviour in:

Java Updater.app/Contents/MacOS/Java Updater

Java Updater simply runs on a schedule in the LaunchAgent, and it has no connection to the JRE's settings. It is not even linked to any Java libraries that would read these settings in a structured manner.

No matter what settings may be put in place in deployment.properties pertaining to updates when the checkbox is checked/unchecked, Java Updater will still launch on schedule with a Sparkle popup that prompts the user to update, even if the user is not an administrator and has no admin privileges required to install software. 


Frequency:

Always


Steps to Reproduce:

1. Open the Java Control Panel, uncheck "Check for Updates Automatically."
2. Either:
- wait for the scheduled time in StartCalendarInterval in the Java-Updater LaunchAgent
- modify the LaunchAgent so that it triggers within a short time from now
- launch Java Updater manually in a Terminal:

/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java\ Updater.app/Contents/MacOS/Java\ Updater


Expected Result:

If I uncheck "Check for Updates Automatically", and the scheduled check time arrives, I expect it to not check and to not prompt me to download an updated version that I may not even have sufficient privileges to install.


Actual Result:

The updater dialog appears.


Error messages:
Exact text of any error message(s) that appeared or any trace information available. Please paste the contents of the log file created (For example: hs_err_pid2416.log) as a result of this crash.

export JPI_PLUGIN2_DEBUG=1

/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java\ Updater.app/Contents/MacOS/Java\ Updater 
2013-02-22 19:41:57.448 Java Updater[3801:507] Found bundle at NSBundle </Library/Internet Plug-Ins/JavaAppletPlugin.plugin> (not yet loaded)
2013-02-22 19:41:57.450 Java Updater[3801:507] Current bundle version = 1.7.13.20
2013-02-22 19:41:58.583 Java Updater[3801:507] updater:didFinishLoadingAppcast:
2013-02-22 19:41:58.584 Java Updater[3801:507] appcast = <SUAppcast: 0x7fe3a0c1e570>
2013-02-22 19:41:58.585 Java Updater[3801:507] updater:didFindValidUpdate:
2013-02-22 19:41:58.585 Java Updater[3801:507] item = <SUAppcastItem: 0x7fe3a2056300>
2013-02-22 19:41:58.585 Java Updater[3801:507] URL = http://javadl.sun.com/webapps/download/GetFile/1.7.0_15-b03/unix-i586/jre-7u15-fcs-bin-b03-macosx-x86_64-15_feb_2013_au.dmg
2013-02-22 19:41:58.585 Java Updater[3801:507] title = Version 1.7.0_15 (build b03)
2013-02-22 19:42:01.711 Java Updater[3801:507] Finished update attempt


Workaround:
Please provide a temporary method for bypassing this bug, if you have found one.


Delete the symlinks in /Library/LaunchAgents and /Library/LaunchDaemons so that these jobs never run. This is a rather severe workaround and I'd much rather not touch any installed files.

It's also severe for another reason: if one instead runs "launchctl unload -w" to disable the LaunchAgent and LaunchDaemon permanently, the JRE installer packages for future versions will fail to install, because the last two lines of its postinstall script make the assumption that the job is not disabled, and because the script will exit non-zero, the entire installation will fail.

This issue doesn't impact end users but it seriously impacts organizations deploying the JRE and supporting Java applications run internally. The issue will be experienced by nearly every system administrator deploying JRE 7 to users who are not administrators on their own machines, and many are accustomed to permanently disabling LaunchDaemon jobs. The fact that the quickest, most obvious solution results in more issues deploying future updates is a serious problem.

Another workaround is to set a non-working URL for the Sparkle SUFeedURL in the plugin bundle Info.plist. The check will still occur on a schedule, but will silently fail and won't prompt the user. Again, this is not a viable workaround.

None of these measures would be necessary if there were simply a supported method (that actually worked) to disable the update check.


Severity:

* Difficult to make even minimal progress without resolving this bug.