JDK-8066985 : Java Webstart downloading packed files can result in Timezone set to UTC
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u25,8u31
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-12-09
  • Updated: 2015-09-29
  • Resolved: 2015-05-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u60 b18Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Same issue report as bug#JDK-8025879 

Java Version: 
    happend Windows 7 even with Java 8 Update 25. 

Description: 

Like the test case in bug#8025879, if Pack200 compressed jars are downloaded 
during a given Java Web Start application run, then the Java default timezone 

is UTC rather than the time zone set for the machine. 

 If the same application is run again with all the jars cached, then the 
proper time zone is used. 

Issue also is applicable to jdk9, but it will be addressed by https://bugs.openjdk.java.net/browse/JDK-8073187
Comments
webrev: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.02/
24-03-2015

Further information This was reproducible in both Java 8 Update 25 and in the latest available Update 31 build. I believe all that's necessary to reproduce this is an applet that (1) is delivered via Pack200 compressed jars (2) uses TimeZone.getDefault()'s results thereafter. The TimeZone is inappropriately UTC only in applet runs where the jars are downloaded in the same run (e.g. after you clear the JRE jar cache). In runs where the jars were previously downloaded the timezone is just fine.
17-12-2014

SQE OK to defer not a recent regression from CPU15_01
10-12-2014

15_01 - defer req justification: No cycles left to address for 15_01 - will resolve for 15_02.
10-12-2014