-
Bug
-
Resolution: Fixed
-
P2
-
6u10, 6u21, 7
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2192929 | 6u21 | Jonathan Gibbons | P3 | Resolved | Fixed | b05 |
JDK-2165660 | OpenJDK6 | Joe Darcy | P2 | Resolved | Fixed | b13 |
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.
- backported by
-
JDK-2165660 javac returns incorrect value for lastModifiedTime() when source is a zip file archive
-
- Resolved
-
-
JDK-2192929 javac returns incorrect value for lastModifiedTime() when source is a zip file archive
-
- Resolved
-
- duplicates
-
JDK-6835451 Change in javac 6 forces recompilation of all source
-
- Closed
-
-
JDK-6949018 javac -Xprefer:newer not working for classes in zip files
-
- Closed
-
-
JDK-6738530 Up-to-date class in archive on 'sourcepath' is recompiled
-
- Closed
-
- relates to
-
JDK-6962236 backport JavacFileManager fixes from 7 to 6-open
-
- Resolved
-
-
JDK-8025157 Source not preferred over bootclasspath causing build problems
-
- Closed
-
-
JDK-6901772 Builds with BOOTDIR jdk6u4 and newer build failures, source timestamp related
-
- Closed
-