The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of the quality outreach sent to the projects involved. To learn more about the program, and how-to join, please check here.

java.io.File.delete No Longer Deletes Read-Only Files on Windows

File.delete has been changed on Windows so that it now fails and returns false for regular files when the DOS read-only attribute is set. Prior to JDK 25, File.delete would delete read-only files by first removing the DOS read-only attribute before attempting deletion. However, because removing the attribute and deleting the file are not a single atomic operation, this could result in the file remaining but with modified attributes if the deletion failed. Applications that depend on the previous behavior should be updated to clear the file attributes before deleting files.

To ease the transition, a system property has been introduced to restore the previous behavior. Running with -Djdk.io.File.allowDeleteReadOnlyFiles=true will cause File.delete to remove the DOS read-only attribute before attempting deletion, restoring the legacy behavior.

See https://bugs.openjdk.org/browse/JDK-8355954 for more details.

File Operations on Windows Fail When Pathnames End with a Trailing Space

File operations on a path with a trailing space in a directory or file name, e.g. “C:\SomeFolder\SomeFile “, now fail consistently on Windows. For example, File::mkdir will return false, or File::createNewFile will throw IOException if an element in the path has a trailing space. Such pathnames are not legal on Windows. Prior to JDK 25, operations on a File created from such an illegal abstract pathname could appear to succeed when in fact they did not.

See https://bugs.openjdk.org/browse/JDK-8354450 for more details.

~