Java: путь против файла

Для новых приложений, написанных на Java 7, есть ли какая-либо причина использовать java.io.Fileобъект больше или мы можем считать его устаревшим?

Я верю, что java.nio.file.Pathможет сделать все, что java.io.Fileможет сделать и даже больше.

Короче говоря:

java.io.FileСкорее всего, никогда не будет осуждается / не поддерживается. Тем не менее, java.nio.file.Pathявляется частью более современной java.nio.fileбиблиотеки и делает все java.io.Fileвозможное, но в целом лучше и больше.

Для новых проектов используйте Path.

И если вам когда-либо понадобится Fileобъект для наследства, просто вызовите Path # toFile ()

Миграция из файла в путь

Эта страница Oracle выдвигает на первый план различия и карты java.io.File functionalityвjava.nio.file lib (including Path) functionality

Статья Дженис Дж. Хейсса и Шарон Захур, май 2009 г., посвященная обсуждению файловой системы NIO.2 в JDK 7

мы можем считать это устаревшим?

Нет, вы не можете считать его устаревшим, если только он не помечен в FileJavadoc.

Проверьте эту статью для получения дополнительной информации - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

По сути, file.Path будет способом идти дальше, но, как широко известно, Java-люди склонны сохранять обратную совместимость, поэтому я думаю, именно поэтому они оставили это.

Я завершу очень хороший ответ @mmcrae.

есть ли какая-либо причина использовать объект java.io.File больше или мы можем считать его устаревшим?

Классы JDK очень редко осуждаются.
Вы можете увидеть в списке устаревших API JDK 8 все классы, которые устарели с момента первого выпуска JDK.
Он содержит лишь небольшую часть классов, которые не рекомендуется использовать в документации Oracle и сообществе Java.
java.util.Date, java.util.Vector, java.util.Hashtable... , что классы с таким количеством дефектов не рекомендуется.
Но почему ?
Потому что концептуально что-то из deprecatedсредств все еще существует, но не рекомендуется использовать, поскольку это, безусловно, будет удалено.
Тысячи программ полагаются на эти плохо разработанные классы.
Для таких классов разработчики Java API не подадут такой сигнал.

Ответ @EJPнастолько правдив:

Не до тех пор, пока это не будет отмечено в Javadoc.

Итак, я думаю, что ваш вопрос будет иметь больше смысла в терминах:
«Поскольку у нас есть выбор, следует ли нам использовать java.io.Fileили java.nio.file.Pathдля новых разработок, и если ответ будет java.nio.file.Path, вы могли бы легко воспользоваться преимуществами java.io.Fileдля использования устаревших проектов java.io.File?»

Я считаю, что java.nio.file.Path может делать все, что может сделать java.io.File, и даже больше.

У вас есть ответ.

Этот урок оракула о устаревших IO подтверждает ваше мышление.

До выпуска Java SE 7 java.io.Fileкласс был механизмом, используемым для файлового ввода-вывода, но у него было несколько недостатков.

Многие методы не генерировали исключения, когда они терпели неудачу, поэтому было невозможно получить полезное сообщение об ошибке. Например, если удаление файла завершилось неудачно, программа получит сообщение «Ошибка удаления», но не узнает, произошло ли это из-за того, что файл не существует, у пользователя нет прав доступа или возникла другая проблема.

Метод переименования не работал согласованно на разных платформах. Не было реальной поддержки символических ссылок.

Требуется дополнительная поддержка метаданных, таких как права доступа к файлу, владелец файла и другие атрибуты безопасности.

Доступ к метаданным файла был неэффективным.

Многие из методов File не масштабируются. Запрос большого списка каталогов на сервере может привести к зависанию. Большие каталоги могут также вызвать проблемы с ресурсами памяти, что приведет к отказу в обслуживании.

Невозможно было написать надежный код, который мог бы рекурсивно обходить файловое дерево и отвечать соответствующим образом, если были круглые символические ссылки.

Имея так много недостатков java.io.File, нам не нужно оснований использовать этот класс для новых разработок.
И даже для использования устаревшего кода java.io.FileOracle дает советы по использованию Path.

Возможно, у вас есть унаследованный код, который использует java.io.File и хотел бы воспользоваться преимуществами функциональности java.nio.file.Path с минимальным воздействием на ваш код.

Класс java.io.File предоставляет метод toPath, который преобразует экземпляр файла старого стиля в экземпляр java.nio.file.Path следующим образом:

Path input = file.toPath();

Затем вы можете воспользоваться богатым набором функций, доступных классу Path.

Например, предположим, что у вас есть код, который удалил файл:

file.delete();

Вы можете изменить этот код для использования метода Files.delete следующим образом:

Path fp = file.toPath();
Files.delete(fp);

Да, но многие существующие API, включая собственные стандартные API Java7, все еще работают только с Fileтипом.

Java.io.File не является устаревшим. Да, java.nio.file.Path лучше, но пока есть много программ и учебников, использующих Java.io.File, хотя бы по устаревшим причинам, его не следует считать устаревшим, это слишком важно. Это просто бросило бы гаечный ключ в работу без всякой выгоды. Например, платформа Android использует File для некоторых из своих основных функций обработки файлов, многие другие вещи делают.

Есть ли какая-либо причина использовать объект java.io.File для новых приложений, написанных на Java 7, или мы можем считать его устаревшим?

Это немного похоже на высказывание: «должен ли Наполеон вторгаться в Россию или эти брюссельские капусты действительно вкусные?»

Что касается второй части вопроса, вы действительно можете считать ее устаревшей. По состоянию на январь 2018 года он не является устаревшим. Но ничто не мешает вам считать это так. Невозможно сказать, принесет ли это вам какое-либо преимущество в этой жизни или в следующей.