1️⃣ ❌ File::delete no longer deletes read-only files

It will now fail (e.g., return false / throw via Files.delete).

Mitigation: clear the read-only flag first:

Path p = Path.of("C:\\data\\report.txt");

Files.setAttribute(p, "dos:readonly", false); // or:

// new File("C:\\data\\report.txt").setWritable(true);

Files.delete(p);

2️⃣ 🚫 File no longer accepts paths with trailing spaces

Inputs like "C:\\data\\folder " are rejected.

Mitigation: sanitize user input before creating File/Path:

String cleaned = pathString.stripTrailing();

Path p = Path.of(cleaned);

3️⃣ ✅ File now correctly processes \\?\-style paths

\\?\ is the Windows extended-length path prefix (e.g.,

\\?\C:\very\long\path\file.txt or \\?\UNC\server\share\file.txt).

It bypasses legacy normalization/length checks so you can handle long paths precisely.

WHAT THIS MEANS FOR YOU

- Add a step to unset DOS read-only before deletions.

- Validate & trim file paths from configs, user input, or env vars.

- Prefer Path/Files APIs over legacy File for richer error handling.

- If you manage very long or UNC paths, consider the \\?\ prefix explicitly.

Ship safe on JDK 25 by tightening file-system hygiene now. 🔧

#Java25 #Windows #JDK #FileIO #BackwardCompatibility #SoftwareEngineering #JavaTips