Preferring class files to source files in ClassReader.java

[Jonathan Gibbons]

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 <mailto: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
>         <mailto: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/4f4c996c/attachment.html