Preferring class files to source files in ClassReader.java

[Jeremy Manson]

I mean that if adate == bdate, then it will always pick b, regardless of
whether it is source or class.

Perhaps that's what you want, but it seems brittle.

Jeremy


On Mon, Jan 13, 2014 at 4:39 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>  I'm not sure what you mean about preferring the first encountered: are
> you referring to javac, or to some modified version?   I completely agree
> that the preference should be preference should be consistent and
> deterministic.
>
> -- Jon
>
>
> On 01/13/2014 04:11 PM, Jeremy Manson wrote:
>
> Bump, because of JDK9 opening (I somehow missed the conversation after my
> last message - sorry about abandoning the thread mid-stream).
>
>  I'd say that regardless of which you choose, it should probably be
> consistently preferring source or classfile.  Right now, the preference
> depends on what it happens to encounter first, which is rather
> unpredictable.  Anyone actually relying on this behavior is doing something
> deeply brittle, since a small refactoring of their build rules can change
> which they get.
>
>  Once the decision has been taken to pin it down one way or the other,
> I'm not averse to a flag or something.
>
>  Jeremy
>
>
>  On Thu, Nov 14, 2013 at 11:22 AM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>>  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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140113/d4ed8669/attachment-0001.html