Home > Bug reporting, Java > Filing bugreports with Oracle for Mac OS X’s Java 7

Filing bugreports with Oracle for Mac OS X’s Java 7

February 23, 2013 Leave a comment Go to comments

Want to file a bug report about an issue having to do with Java 7 for OS X? It can be tricky to find the right place to submit it, so here’s some guidance for filing it in the right place.

Update: I’ve been informed that it is necessary to install the current JRE of Java 7 from the Oracle JDK7 test site before Oracle will accept bug reports from you.

JDK7 is available from http://jdk7.java.net/, with the download site being http://jdk7.java.net/download.html.

The reason that Oracle does it this way is that they want customers to use Oracle Java SE Support. This is for-pay support and Oracle’s preferred way for non-developer customers to get support.

All that said, if the issue you’re running into also occurs on the JRE from the Oracle JDK site, file a bug using the procedure below.

For example, here’s how to file a bug report for the Java 7 installer for OS X.

1. Go to http://bugreport.sun.com/bugreport/

2. Scroll down to the Submit a Bug section

3. Check the box for Check this box to indicate that you understand this is not a place to receive support….

4. Click the Start a new Report button.

Screen Shot 2013-02-22 at 7.12.14 PM

5. On the next page, go to the Start A Report: section

6. For an installer bug, select the following:

Type: Bug

Product/Category: Java Platform Standard Edition (JDK/JRE)

Subcategory: JDK/JRE installation (install)

Release: Java Platform Standard Edition 7

Operating System: Mac OS X 10.7 (Oracle VM)

7. When ready to proceed, click the Continue button.

Screen Shot 2013-02-22 at 7.14.19 PM

8. On the next page, provide the information requested to file your bug report and click the Submit button when completed.

Screen Shot 2013-02-22 at 7.20.53 PM

Good luck! Filing bug reports doesn’t guarantee that your problem will be fixed, but it raises the odds that it will be. Not filing it may mean that Oracle is completely unaware of the problem and thus will never fix it.

Categories: Bug reporting, Java
  1. Tim Sutton
    February 23, 2013 at 1:00 am
    Reply

    Thanks Rich!

    The details of my bug report are pasted here:


    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.

    view raw

    jre_update_check_bug_report

    hosted with ❤ by GitHub

  1. No trackbacks yet.

Leave a Reply

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

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com 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 )

Cancel

Connecting to %s

%d bloggers like this: