JDK-6791805 : Pack200 unpacker implementation can set timezone to utc
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u10
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2009-01-09
  • Updated: 2015-02-17
  • Resolved: 2013-05-21
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
robo@saiph:~/src/bios$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
robo@saiph:~/src/bios$ uname -a
Linux saiph 2.6.27-7-generic #1 SMP Thu Oct 30 04:18:38 UTC 2008 i686 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
Using several threads to load pack200 files can set the default timezone information to utc.

UnpackerImpl.unpack looks something like this:
-------------------------------------------------------
TimeZone tz = TimeZone.getDefault();
try {
  TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
   ... do some stuff ...
} finally {
  TimeZone.setDefault(tz);
}
--------------------------------------------------------

If a second thread enter unpack while a first thread is inside the try-block, then that second
thread will get tz=UTC (and later on set default to UTC, in the finally).

UnpackerImpl.unpack should not set a default timezone, if it needs to calculate timezone distances it should do just that, get a time delta between current time and UTC.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We have an applet that uses a lot of different jar files. The jar files are arranged in an order that makes the applet start by loading only the first pack200/jar-file. Once the applet has started it starts a thread that loads the other pack200/jar-files on a background thread. If the user starts to do actions the normal class loading occurrs on the edt.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correct timezone every time.

ACTUAL -
Sometimes we get date information that differ from the expected value.

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
1) Stop using our background thread to pre-load the other jar-files. This of course means that the user will
    get a slower loading system.

2) use webstart (which we can do as well).

Comments
As mentioned before zip archives have a serious limitations to carry TIme/Date it uses an old Windows time format, and does not allow DST to be carried, hence we keep everything in UTC. and this cannot be changed.
21-05-2013

EVALUATION Yes the packer sets all the timestamps to UTC because of various timezone issues and deficiencies of the zip format.
03-08-2010