Re: JDK 25 feature set is now frozen!

Hello Stefan,

On 26/06/25 5:16 pm, Stefan Bodewig wrote:
 > On 2025-06-26, Jaikiran Pai wrote:
 >
 >> However on Windows we are seeing a large number of test failures. I
 >> looked into those failures and those all relate to the "heads up"
 >> section in your mail about
 >> https://jdk.java.net/25/release-notes#JDK-8355954. In the Ant
 >> testsuite there are several tests which attempt a
 >> java.io.File.delete() on a read-only file. Until Java 25, that call
 >> would delete the file.
 >
 >> As noted in the linked change, that's no longer the case by default in
 >> Java 25. I manually updated the Ant testsuite to set the newly
 >> introduced -Djdk.io.File.allowDeleteReadOnlyFiles system property to
 >> true and that got all those tests to pass on Windows too.
 >
 > Maybe we should change the tests, rather than set the system property?

Yes, that's an option too. For reference, this is the run against 
Windows which shows these failures 
https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Windows%20(latest%20EA%20JDK)/74/

That failure number is exaggerated by the fact that several of these 
failures are due to a side effect of few tests creating a read-only file 
then failing to delete it. Subsequent tests then use that same file 
(through the "touch" task) and check whether it's writable and notice 
that it isn't and that causes a lot of those tests to fail.

 > Is the file read-only on non-Windows platforms as well?

In our tests, yes.

 > To me the description of the change doesn't say what the behavior is 
on other
 > platforms. Is Windows the only one that now will not delete read-only
 > files - or is it the only one where read-only files would have been
 > removed prior to Java 25?

On *nix platforms a File.delete() completes successfully (and returns 
true) for a read-only file, because the underlying *nix platform allows 
that. So it's only on Windows where the File.delete() will no longer 
succeed (and will returns false) against these read-only files. 
Previously, before https://bugs.openjdk.org/browse/JDK-8355954 got fixed 
recently, (only) on Windows the internal implementation of the JDK was 
removing the read-only attribute from the file before doing the delete, 
which is why the delete would succeed and we didn't notice this issue.

 > Also we could modify FileUtils.tryHardToDelete to remove the read-only
 > flag if we feel this is something that may hit Ant's users. After all it
 > has bitten our own testsuite.

I haven't given it a deeper thought. I think once we take care of these 
antunit test failures in the testsuite, then it might give us a better 
picture if there are actual scenarios where some code intentionally 
wants to detail a read-only file. If there exists such a use case, then 
since the JDK is already providing a way to delete such files (through 
the use of this system property), then we would need to evaluate if we 
still want to add some code in FileUtils.tryHardToDelete or advice users 
to use that system property instead.

In the next few days I will go over these tests to see how we can 
address these issues and if the usage of the new system property can be 
avoided.

-Jaikiran