Oracle has released a new update for Java 8, but this update has an interesting wrinkle. Oracle has put out a new build of Java 8, but didn’t bump the version number from Java 8 Update 31. So folks who had previously installed Java 8 Update 31 may receive a message to update to Java 8 Update 31 from their current version, which will also be Java 8 Update 31.
This may lead to some confusion.
Update 2-16-2015: It appears that the update feed for Java 8 Update 31 has been updated to reference 220.127.116.11 (aka Java 8 Update 31 build 13):
There’s no information available on why the change was made. My speculation is that Oracle decided that updating the Sparkle feed for Java 8 Update 31 so that it was no longer providing Java 8 Update 31 build 15 as an update for Java 8 Update 31 build 13 was the best way to help avoid future confusion over updates for Java 8 Update 31.
It looks like 18.104.22.168 (aka Java 8 Update 31 build 15) is still the version being provided through the Java download site:
I checked the update feeds for Java 8 Update 20 and Java 8 Update 05 and both of those feeds are still providing 22.214.171.124 as well:
Unfortunately, there is still no information available about Java 8 Update 31 build 15 and how it differs from Java 8 Update 31 build 13.
Build numbers for the two Java 8 Update 31 releases
January’s Java 8 Update 31 (released on January 20, 2015): Java 8 Update 31 build 13
February’s Java 8 Update 31 (released on February 10, 2015): Java 8 Update 31 build 15
If you have Java 8 Update 31 installed, you can find out which build you have by running the following command in Terminal:
defaults read /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist CFBundleVersion
If you have Java 8 Update 31 build 13, the following string will be returned:
If you have Java 8 Update 31 build 15, the following string will be returned:
Following installation of Java 8 Update 31 build 15, I tested on a 10.10.2 Mac against the following sites:
My work’s Juniper VPN
Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml
Java Tester’s Java Version page: http://javatester.org/version.html
With Oracle’s Java 8, there’s been some confusion as to whether Java 8 runs on Mac OS X 10.7.5. This issue was lent additional urgency in the wake of Oracle’s announcement that they will begin auto-updating Java 7 users to Java 8 starting in January 2015.
The root of the confusion lies in the fact that Oracle has listed two different sets of system requirements on their website for Macs running Java 8 on Mac OS X.
The first set is available via Oracle’s general Java system requirements page. This page states that Java 8 requires the following:
- Intel-based Mac running Mac OS X 10.8.3+, 10.9+
- Administrator privileges for installation
- 64-bit browser
- Intel-based Mac running Mac OS X 10.7.3 (Lion) or later.
- Administrator privileges for installation
- 64-bit browser
In short, the question of Java 8 support for 10.7.x depended on which system requirement page was correct. For more details, see below the jump.
To go along with my earlier post about automating Oracle Java 7 updates, I’ve also posted a script to download and install the latest Java 8 update from Oracle. The method is identical, with the exception of referring to Java 8’s SUFeedURL value in Java 8’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file.
For more information, see below the jump.
Something I’ve wanted to do for a while was to write a script to download and install the latest Java 7 update from Oracle. I’ve been using AutoPkg to download the latest Java 7 updates using AutoPkg’s OracleJava7 recipes, but I wanted to develop a script that would do the following:
- Download the latest Java 7 installer from Oracle’s website
- Install the latest Java 7 update
- Clean up after itself
Oracle didn’t make this an easy task, as the download URL seems to change on a per-update version. AutoPkg handles its update task by scraping Oracle’s manual download page for the current correct URL to use.
Oracle does provide a Sparkle-based update mechanism for Java 7 on OS X, so I wanted to see if there was a way to leverage that to pull down updates. The only address I could find in that regard was the SUFeedURL value included in Java 7’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file. I checked that value using the following command:
defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" SUFeedURL
The output I received for Java 7 Update 67 was the following:
I decided to see what output would come back from Oracle’s site when accessed, so I used the following curl command to see what was returned:
/usr/bin/curl --silent https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml
The following XML was returned and I was gratified to see that it contained a download link to a Java 7 Update 67 disk image.
One of the important things I was able to establish is that the XML address embedded with Java 7 Update 67 is not special in this regard. As part of my testing, I verified that using the SUFeedURL value for Java 7 Update 15 and 65 will also work to pull the address of the latest Oracle Java 7 installer disk image.
Using this information, I was able to build a script that can download and install the latest Java 7 update. See below the jump for details.
It’s been a long time coming, but Java 6 on OS X has hit the end of the road for updates. Mike Swingler has posted a message to the Apple java-dev list that confirms that no further Java SE 6 updates are available for any platform, including OS X. Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are the latest versions available and install Java SE 6 build 1.6.0_65.
As part of this post, I’d like to say thanks to the Java folks at Apple for going above and beyond. Apple’s last Java 6 update was released in Oct 15, 2013, which was a full eight months after Oracle discontinued updates for other platforms. This allowed some vulnerabilities in Java 6 to be addressed that otherwise wouldn’t have been.
For those who need them, download links for Java for OS X 2013-005 and Java for Mac OS X v10.6 Update 17 are available below:
Oracle’s Java 7 Update 51 has introduced new security requirements for browser plugins for applets and web start applications. However, not all applets are able to run using the new requirements. To help with this, Oracle has included a way to whitelist specific sites using Java 7’s new Exception Site List. This allows the applets and web start applications hosted on the specified sites to continue to work, even if they don’t meet the new security requirements in Java 7.
On Mac OS X 10.7 and higher, the Exception Site List is a plaintext file named exception.sites, which is stored in /Users/username/Library/Application Support/Oracle/Java/Deployment/security.
To help Mac admins manage the Exception Site List, I’ve written a script which is designed to add websites to Oracle’s Java 7’s Exception Site List without overwriting existing entries. For more details, see below the jump.
Older versions of Java applets used by Juniper’s SSL VPN may be blocked from working properly by security changes in Java 7 Update 51. When the applet is blocked, an error message like this will appear:
SecurityException: Missing required Permissions manifest attribute in main jar: https://server.name.here/dana-cached/sc/JuniperSetupClientApplet.jar
The root cause is that Java 7 Update 51 now requires the existence of the referenced permissions attribute, along with a requirement to code sign all Java applets. The applets used by older versions of Juniper’s SSL VPN do not include the permissions attribute.
The fix is to update the SSL VPN with Secure Access (SA) version 7.1R17, 7.3R9, 7.4R7, 8.0R1 and later versions. The applets included with these versions have the needed permissions attribute. Until the VPN server is upgraded, Juniper’s recommended workaround is use Java 7 Update 51’s Exception Site List feature. To help with this, I have a post showing how to add sites to the Exception Site List in the Java Control Panel settings.