RFR: timestamp oddities -sourcepath vs zip/jar

Andreas Lundblad andreas.lundblad at oracle.com
Thu Dec 12 01:44:07 PST 2013

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
        use src/X.java
else if (boot/X.class exists)
    use boot/X.class
else if (classpath/X.class exists)
    use classpath/X.class
    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

More information about the compiler-dev mailing list