RFR: timestamp oddities -sourcepath vs zip/jar

[Andreas Lundblad]

On Thu, Sep 26, 2013 at 01:42:34AM -0700, Jonathan Gibbons wrote:
> Martin,
> 
> Your proposal is phrased somewhat better than the earlier one, but
> realistically, it is too late to do anything in this area for JDK 8.
> 
> What I disliked about the earlier proposal was the special casing of
> zip/jar files which was just plain wrong. Here, you are implicitly
> suggesting a better rule, which is based more on the logical paths
> involved (i.e. sourcepath, classpath, bootclasspath) than the nature
> of the file.   Effectively, you are saying that in javac's game of
> rock-paper-scissors, sourcepath beats bootclasspath, no matter what
> the timestamps say.  This behavior could be embodied in a new value
> for the -Xprefer option, leaving the existing behaviors unchanged.
> 
> -- Jon


Here's a summary of my understanding of the problem:

When (implicitly) compiling .java-files of classes that also have a corresponding .class-file on the boot classpath, the default behavior (-Xprefer:newer) might select the boot classpath .class-file in favour of the sourcepath .java-file.

While this behavior is not wrong, it may be surprising for users not realizing that the timestamps of files inside for instance rt.jar, actually affects the compilation.

The natural workaround would be to use -Xprefer:source, however (quoting Fredrik)

> -Xprefer:source is not good enough because it will recompile
> everything indiscriminately on the sourcepath even
> though the class has already been compiled and exists in bin.

To remedy this, the suggestion now is to add a third Xprefer option that says:

if (src/X.java exists)
    if (dest/X.class exists and is newer)
        use dest/X.class
    else
        use src/X.java
else if (boot/X.class exists)
    use boot/X.class
else if (classpath/X.class exists)
    use classpath/X.class
else
    X not found


Here are two observations:

1. The only difference compared to -Xprefer:source would be the part

    if (dest/X.class exists and is newer)
        use dest/X.class

i.e. the part that says "don't recompile stuff already present in dest". So, before moving on with this, I would like to ask, is this behavior _only_ interesting in conjunction with -Xprefer:source, or could it be useful also with -Xprefer:newer? If so, we might want to consider adding something like -Xnorecompile instead. (Of course, if we're sure that such option would never be useful without -Xprefer:source, we should probably go with a third -Xprefer option.)

2. The solution proposed by Martin would, as far as I can tell, be equivalent to having "-d dest -Xbootclasspath/p:dest". Is this correct?


-- Andreas