Preferring class files to source files in ClassReader.java
Jonathan Gibbons
jonathan.gibbons at oracle.com
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 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
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