JDK-4981560 : ZipEntry.dosToJavaTime() uses deprecated (and thread-blocking) Date constructor
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-01-22
  • Updated: 2015-02-19
  • Resolved: 2009-04-06
Related Reports
Relates :  
JDK-4614842 - Performance improvements to GregorianCalendar and Date
Relates :  
JDK-8073497 - Lazy conversion of ZipEntry time
Description

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 :
EXPECTED -
No thread contention should occur.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Do not use ZipEntry.getTime()
(Incident Review ID: 230438) 
======================================================================
Comments
EVALUATION closed as "not reproducible", see evaluation above.
06-04-2009
EVALUATION Some bug archeology suggests that the performance problem has been addressed in the fix to 4614842: Performance improvements to GregorianCalendar and Date Perhaps Masayoshi could confirm this? It is still true that the JDK should set a good example and not use a deprecated API. There is no urgency to get this into Tiger, however. ###@###.### 2004-01-23 The submitter notes that: "dosToJavaTime is called even when the application is running on Solaris." This is intentional and normal, since DOS time stamps are used in Zip files. ###@###.### 2004-01-23 ###@###.### writes: "I realized that the DOS time is expected to be local time (which is somehow strange to me). The Date class has an advantage to call a java.util package private method in TimeZone to avoid cloning the default TimeZone object, which was another performance problem of Calendar and Date before Tiger. So I'd recommend to leave the dos/java time conversions as is. We should be able to confirm that the thread contention problem reported by 4981560 is gone in Tiger." Therefore, I intend to close this as Can Not Reproduce. The submitter could verify that the problem has been fixed in Tiger or one of its betas, which are due to be released soon. ###@###.### 2004-01-26
26-01-2004