JDK-6725036 : javac returns incorrect value for lastModifiedTime() when source is a zip file archive
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u10,6u21,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-07-11
  • Updated: 2016-03-23
  • Resolved: 2011-05-18
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 6 JDK 7 Other
6u21Fixed 7 b32Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
JDK-6835451 - Change in javac 6 forces recompilation of all source
Duplicate :  
JDK-6738530 - Up-to-date class in archive on 'sourcepath' is recompiled
Duplicate :  
JDK-6949018 - javac -Xprefer:newer not working for classes in zip files
Relates :  
JDK-8025157 - Source not preferred over bootclasspath causing build problems
Relates :  
JDK-6962236 - backport JavacFileManager fixes from 7 to 6-open
Description
The proposed new javap -sysinfo option has revealed a bug in the value of lastModifiedTime() used internally by javac when a class comes from a zip file archive.

Here is the output for java.lang.String:

JavapTask: /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/rt.jar(java/lang/String.class) 
Classfile jar:/usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/rt.jar!java/lang/String.class
Last modified Jan 11, 1970; size 15572 bytes
MD5 checksum 6977f62c32cd39574a15a1fde238fc74

(Note:  Jan 11, 1970)

Here is the corresponding output from unzip:
    15572  09-24-07 22:49   java/lang/String.class
and from jar
 15572 Mon Sep 24 22:49:32 PDT 2007 java/lang/String.class

This needs to be fixed, as javac uses last modified time internally to determine if class files are up to date.
Comments
EVALUATION For reference, here is the relevant code from dosToJavaTime in java.util.Zip /* * Converts DOS time to Java time (number of milliseconds since epoch). */ private static long dosToJavaTime(long dtime) { Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80), (int)(((dtime >> 21) & 0x0f) - 1), (int)((dtime >> 16) & 0x1f), (int)((dtime >> 11) & 0x1f), (int)((dtime >> 5) & 0x3f), (int)((dtime << 1) & 0x3e)); return d.getTime(); } Note however, this code uses a deprecated Date constructor, with the following comment * @deprecated As of JDK version 1.1, * replaced by <code>Calendar.set(year + 1900, month, date, * hrs, min, sec)</code> or <code>GregorianCalendar(year + 1900, * month, date, hrs, min, sec)</code>.
11-07-2008
EVALUATION The following code in ZipFileIndex looks "suspicious" // From java.util.zip private static long dosToJavaTime(int nativetime) { // Bootstrap build problems prevent me from using the code directly // Convert the raw/native time to a long for now return (long)nativetime; }
11-07-2008