I've discovered what seems like buggy behavior with Java 8u40 settings sticking, and I'm hoping someone else might've already encountered this and can point me in the right direction. Obviously, one can deploy Java 8 (even update 40) fairly simply, with known techniques:
https://derflounder.wordpress.com/2015/03/04/oracles-java-8-update-40-the-good-the-bad-and-the-ugly/
However, some of our environments are not particularly well-suited to updating Java every time a new version comes out, due to possible compatibility issues with web apps, interfaces on various network appliances, or, in this case, standardized tests like PARCC. We cannot have our users (K-8 students, in our case) being prompted to update Java when they're trying to take the PARCC tests – it confuses the students, the teachers, and neither one of them has the administrative power to update Java on student machines anyway.
Thus, we need the ability to suppress these updates. This looks fairly simple, at first blush. There's a "deployment.properties" file (located in ~/Library/Application Support/Oracle/Java/Deployment) with the following line:
deployment.macosx.check.update=true
You can uncheck the "Check for Updates Automatically" checkbox on the Update tab of the Java system preference pane, click OK, enter your administrative credentials, and then go check to see that this line in the deployment.properties file has changed to:
deployment.macosx.check.update=false
Easy enough to package up (with Composer, natch) and deploy to your fleet of Macs, right? Or even to edit with a well-constructed shell script. (See https://jamfnation.jamfsoftware.com/discussion.html?id=8239, for instance.)
Unfortunately... not so fast there, hombre. The minute a user (including a "Standard", non-administrator account) opens the Java system preference pane (which opens in its own window) the preferences revert back to their original settings. This persists even if you add a line right after that (per documentation I found somewhere) as follows:
deployment.macosx.check.update.locked
This even happens if they click "Cancel" instead of "OK" (and neither option requires an administrative password!) I apologize if I've missed something here, but up until a month ago, we had no reason to install Java on our student Macs, so I'm a bit new to this problem.
-Eric