Preferring class files to source files in ClassReader.java

[Jonathan Gibbons]

On 11/13/2013 03:12 PM, Jeremy Manson wrote:
> This was easier than finding all of the places we zap the timestamps 
> and putting in special logic to handle source files separately (note 
> that our users can add zapping logic to their own invocation of jar if 
> they want better caching behavior).
>
> We can certainly keep this local if you guys don't want it - I knew it 
> was borderline when I sent it.  I'll ping this thread again when 9 
> opens up.  Thanks!
>
> Jeremy
>
>

https://bugs.openjdk.java.net/browse/JDK-8028324

-- Jon


> On Wed, Nov 13, 2013 at 3:00 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     On 11/13/2013 02:38 PM, Jeremy Manson wrote:
>
>         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?
>
>
>
>     Since you've gotten in the business of zapping timestamps in jar
>     files anyway, why not zap them more intelligently so that class
>     files have newer time stamps than corresponding source files?
>
>     -- Jon
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131113/1627b755/attachment.html