Підсумки

Висновки

Файл є послідовністю байтів, а її зміст визначає узгоджений формат: кодування, порядок полів, версія та допустимі розміри. Path і Files з NIO.2 будують шляхи й виконують файлові операції, причому відносний шлях залежить від робочого каталогу процесу. Байтові потоки працюють із байтами, символьні – із символами, а перехід між ними потребує явного кодування, зазвичай UTF-8. Ресурси закривають через try-with-resources, а читання в буфер враховує фактично отриману кількість байтів. Перевірка існування не замінює обробки фактичної відмови операції, а обхід каталогів і розпакування архівів потребують контролю меж, посилань і розмірів. Надійне оновлення записує тимчасовий файл і лише після перевірки переміщує його до цілі. Стандартна серіалізація зберігає граф об’єктів, але не повторює валідацію конструктора, тому відновлений стан перевіряють, а для недовірених даних обирають інший формат. Файлову програму тестують в окремому тимчасовому каталозі на звичайних, порожніх, неправильних і обірваних даних.

Підсумкові запитання

1. Чим normalize відрізняється від toRealPath?
2. Чому ресурс закривають навіть після винятку?
3. Коли потрібен байтовий потік, а коли Reader?
4. Який контракт дозволяє простий split у CSV-прикладі?
5. Чому Files.walk потрібно закривати?
6. Що не гарантує ATOMIC_MOVE на довільному провайдері?
7. Чому Serializable не виконує всю предметну валідацію?
8. Які обмеження має ObjectInputFilter?

Корисні посилання

• https://dev.java/learn/java-io/.
• https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/file/Files.html.
• https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/io/ObjectInputFilter.html.
• https://openjdk.org/jeps/400.
• https://openjdk.org/jeps/415.