RFR: 8338675: javac shouldn't silently change .jar files on the classpath
David Beaumont
duke at openjdk.org
Fri Feb 21 10:16:55 UTC 2025
On Fri, 21 Feb 2025 08:31:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
>> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs.
>>
>> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior).
>
> test/langtools/tools/javac/T8338675/NoOverwriteJarClassFilesByDefault.java line 105:
>
>> 103: // it proves it's getting it from the source file in the JAR.
>> 104: Instant olderTime = Instant.now();
>> 105: Instant newerTime = olderTime.plusSeconds(1);
>
> I would slightly prefer to make the time distance longer - maybe 60s. Mostly because (historically?) IIRC some timestamp precision was 2s. It is not a factor here, but given the timestamp is only a number here, we can make the difference larger.
>
> There could also be a second test that would not include the classfile at all - the test would work the same, and would be immune to changes in timestamp/ordering.
Since this is being written manually, and read programatically, I'd rather make the difference as *small* as possible to demonstrate the tie break is performed for any "newer" source file.
I did think about the 2nd test, but that would seem to only check a subset of what this test already checks for.
I happy with this as-is (assuming the 1 second thing doesn't actually cause a failure).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1965224900
More information about the compiler-dev
mailing list