Preferring class files to source files in ClassReader.java

[Joel Borggrén-Franck]

On 14 nov 2013, at 19:44, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> On 11/14/2013 04:03 AM, Joel Borggren-Franck wrote:
>> Hi Jeremy,
>> 
>> On 2013-11-13, 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?
>>> 
>> Thinking out loud here. While I do understand your usecase, don't we
>> want the opposite to be the default case? If javac finds a source and a
>> class file and the timestamps are suspect isn't the responsible thing to
>> do to compile the source again?
>> 
>> cheers
>> /Joel
> 
> I think Jeremy would argue that the timestamps are not suspect -- they are exactly what they have set them to be!
> 


Yes, but javac doesn't know that. In order to make a change like this I think you need to argue it is correct in all cases. I'm not convinced of that yet, but then again I'm not yet convinced of the opposite either.

Could be interesting to compare with how make handles equal timestamps.

cheers
/Joel