Preferring class files to source files in

Jonathan Gibbons jonathan.gibbons at
Thu Nov 14 11:22:39 PST 2013

On 11/14/2013 11:06 AM, Joel Borggrén-Franck wrote:
> On 14 nov 2013, at 19:44, Jonathan Gibbons <jonathan.gibbons at> 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

I think the general take on this discussion is that in JDK 9, we should 
examine the possibility of updating -Xprefer to have more policies 
available.  I'm also open to changing existing policies -- but with some 
concern for compatibility for those who like the existing policies.

-- Jon

More information about the compiler-dev mailing list