Re: JDK 25 feature set is now frozen!

I had a detailed look at these failures. The majority of them were due 
to the tearDown() in these tests no longer able to delete the test 
generated read-only files. That would then cause subsequent tests to 
fail because they weren't expecting a read-only file to be present. I 
fixed that issue through this commit into Ant's repo 
https://github.com/apache/ant/commit/54350f7e967f965169a07f65ec925b621cef231d. 
It's a test-only fix and what it does is, on Windows, before doing the 
tearDown(), it (re)sets the permissions on these test generated files to 
"writable" and then does the delete. That way the tearDown() can delete 
the input/output directories generated by the tests.

Once that was committed almost all tests started passing expect for a 
few in copy-test.xml and move-test.xml 
https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Windows%20(latest%20EA%20JDK)/77/#showFailuresLink. 
Looking at those tests what they do is, they use the copy or move tasks 
with the "force=true" property. These tests fail because even with 
"force=true", the Copy/Move task can no longer delete (and then update) 
a pre-existing read-only file on Windows. This is a functional issue, 
i.e. it means that the copy/move tasks' force=true is no longer 
functional in this specific scenario on Windows. In order to address 
this change in behaviour, I pushed a commit to Ant's repo 
https://github.com/apache/ant/commit/fe3727ee48b5ff89f65de52dea91c1bc757e4705. 
Like I note, this is a change in the production source of Ant in 
FileUtils.tryHardToDelete(). In this change, on Windows, the 
implementation now sets the file to writable if it was read-only and 
File.delete() had failed. It then retries the File.delete(). After this 
change, the remaining test failures on Windows disappear (against Java 
25 EA).

The test results are now back to normal for both Linux and Windows 
against Java 25 EA:

https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Windows%20(latest%20EA%20JDK)/79/

https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/59/

Please take a look at those 2 commits and I would like to hear if those 
look OK or would need to be handled differently. The newly proposed JDK 
property isn't used in these changes and we don't need to set it at 
least for the current tests.

-Jaikiran

On 27/06/25 7:55 pm, Jaikiran Pai wrote:
> 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
>
>