A DESCRIPTION OF THE PROBLEM :
Between 8u45 and 8u60, https://bugs.openjdk.java.net/browse/JDK-8073497 was merged. This changed the behavior of how the JDK picks the default timezone when jars are in use. More specifically, when the main class is in a jar (or in certain other situations where a jar is on the main classpath), then VM startup will trigger timezone selection on 8u45 and before but not on 8u60 or after. This means a program which sets user.timezone programmatically will have different behavior on 8u45 and 8u60 in that circumstance.

On 8u45, the process is:
1. VM tries to load the main class through AppClassLoader
2. AppClassLoader eventually calls JarFile.getJarEntry
3. eventually calls the java.util.Date constructor
4. eventually calls TimeZone.getDefaultRef
5. Timezone is picked based on user.timezone property passed with -D on the command line (if any) or based on the TZ environment variable otherwise

On 8u60, JarFile.getJarEntry does not make a Date. Instead, the timezone is chosen at the first time that the application uses java.util.Date (or TimeZone), at which point it will pick based on the user.timezone which was set by the application (if any) or user.timezone passed with -D on the command line (if any) or based on TZ otherwise.

This change is not documented in the 8u60 release notes, either in
http://www.oracle.com/technetwork/java/javase/8u60-relnotes-2620227.html
http://www.oracle.com/technetwork/java/javase/2col/8u60-bugfixes-2620228.html

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The release notes indicate that the process used to pick the timezone is slightly different, and may take into account `user.timezone` system property set by the application in cases where it previously does not.
ACTUAL -
nothing

URL OF FAULTY DOCUMENTATION :
http://www.oracle.com/technetwork/java/javase/8u60-relnotes-2620227.html