Name: jl125535 Date: 01/21/2004
FULL PRODUCT VERSION :
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b35)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b35, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
The ZipEntry.getTime() method uses a private ZipEntry method called "dosToJavaTime(long)". This method uses the deprecated Date constructor Date(int,int,int,int,int,int) which internally has a synchronized block around a static member variable (which is a java.util.Calendar). This causes thread blocking any time an application has multiple threads calling ZipEntry.getTime().
This greatly limits the scalability of any application which uses the zip package and checks the time stamps (like WebLogic 8.1's checking for modified servlet classes and jsp files).
The dosToJavaTime should be reworked to call Calendar directly instead of using the old Date constructor.
Another option is to rewrite the Date(int year, int month, int date, int hrs, int min, int sec) constructor. Although the constructor is deprecated, other
non-deprecated methods in the jre are invoking it.
Also note that dosToJavaTime is called even when the application is running on Solaris.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create an application that has multiple threads that call ZipEntry.getTime(). One thread will wait for the other to complete.
EXPECTED VERSUS ACTUAL BEHAVIOR :
No thread contention should occur.
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Do not use ZipEntry.getTime()
(Incident Review ID: 230438)