Preferring class files to source files in ClassReader.java
oehrstroem at gmail.com
Thu Nov 14 03:38:20 PST 2013
Interesting. In my opinion timestamps inside a JAR is meaningless.
And the fact that you reset them all the time seems to support that.
What do you think about the related problem here?
2013/11/13 Jeremy Manson <jeremymanson at google.com>
> Hi folks,
> A bit of background:
> - We use a content-addressable storage around here, so to minimize the
> diffs between two JAR files (and get more hits in our content-addressable
> storage), we reset all timestamps in JAR files to the same values.
> - Some of our users include both source and class files in their JAR files.
> - When those users want to put those JAR files on the classpath for javac,
> and use them to compile other files, they may not have included enough on
> the classpath to compile the source files.
> - We've worked around this by favoring classfiles when the two files are
> of the same age. This has the added benefit of not having to recompile the
> source files when they are found.
> - What do you think? Too esoteric? Wait for JDK9?
> diff --git a/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> --- a/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> +++ b/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> @@ -2690,7 +2690,11 @@
> long bdate = b.getLastModified();
> // 6449326: policy for bad lastModifiedTime in ClassReader
> //assert adate >= 0 && bdate >= 0;
> - return (adate > bdate) ? a : b;
> + return (adate > bdate) ? a :
> + (bdate > adate) ? b :
> + // These dates can be equal if the files' timestamps were
> + // In this case, prefer the .class file.
> + (a.getKind() == JavaFileObject.Kind.CLASS) ? a : b;
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev