Preferring class files to source files in ClassReader.java

[Fredrik Öhrström]

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?
https://bugs.openjdk.java.net/browse/JDK-8028196

//Fredrik



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?
>
> Jeremy
>
> diff --git a/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> b/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
> reset.
> +                // In this case, prefer the .class file.
> +                (a.getKind() == JavaFileObject.Kind.CLASS) ? a : b;
>          }
>      }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131114/f2ae4980/attachment.html