Java: ścieżka vs plik

Czy w przypadku nowych aplikacji napisanych w Javie 7 istnieje jakikolwiek powód do używania java.io.Fileobiektu, czy możemy uznać go za przestarzały?

Wierzę, że java.nio.file.Pathmożna zrobić wszystko, co java.io.Filemożna zrobić i więcej.

Krótko mówiąc:

java.io.Filenajprawdopodobniej nigdy nie będzie przestarzałe / nieobsługiwane. To powiedziawszy, java.nio.file.Pathjest częścią bardziej nowoczesnego java.nio.filelib i robi wszystko java.io.File, ale ogólnie lepiej i wiele więcej.

W przypadku nowych projektów użyj Path.

A jeśli kiedykolwiek potrzebujesz Fileobiektu dla starszej wersji, po prostu wywołaj Path # toFile ()

Migracja z pliku do ścieżki

Ta strona Oracle pasemka różnice i mapy java.io.File functionalitydojava.nio.file lib (including Path) functionality

Artykuł Janice J. Heiss i Sharon Zakhour, maj 2009, omawiający system plików NIO.2 w JDK 7

czy możemy uznać to za przestarzałe?

Nie, nie możesz uważać go za przestarzały, dopóki nie zostanie zaznaczony w FileJavadoc.

Sprawdź ten artykuł, aby uzyskać więcej informacji - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

Zasadniczo file.Path będzie odtąd drogą, ale jak powszechnie wiadomo, ludzie Java mają tendencję do zachowania kompatybilności wstecznej, więc sądzę, że właśnie dlatego ją zostawili.

Wypełnię bardzo dobrą odpowiedź @mmcrae.

czy istnieje jakikolwiek powód do używania obiektu java.io.File, czy możemy uznać go za przestarzały?

Klasy JDK są bardzo rzadko przestarzałe.
Możesz zobaczyć na liście przestarzałych JDK 8 API wszystkie klasy przestarzałe od pierwszego JDK.
Zawiera tylko niewielką część klas, których odradza dokumentacja Oracle i społeczność Java.
java.util.Date, java.util.Vector, java.util.Hashtable... że są zajęcia z tak wielu wad nie są przestarzałe.
Ale dlaczego ?
Ponieważ koncepcyjnie coś deprecatedtam oznacza, ale zniechęca do używania, ponieważ z pewnością zostanie usunięty.
Tysiące programów polegają na tych źle zaprojektowanych klasach.
W przypadku takich klas programiści Java API nie dadzą takiego sygnału.

Odpowiedź @EJPjest naprawdę słuszna:

Nie, chyba że i dopóki nie zostanie tak zaznaczony w Javadoc.

Tak, myślę, że pytanie to więcej sensu w jego słowach:
„Jak mamy wyboru, musimy użyć java.io.Filealbo java.nio.file.Pathdo nowych sytuacji i jeśli odpowiedź brzmi java.nio.file.Path, można łatwo wykorzystać java.io.Filedo projektów przy użyciu starszych java.io.File?”

Wierzę, że plik java.nio.ath.ath może zrobić wszystko, co plik java.io.File i więcej.

Masz odpowiedź.

Ten samouczek wyroczni na temat starszych IO potwierdza twoje myślenie.

Przed wydaniem Java SE 7 java.io.Fileklasa była mechanizmem używanym do operacji we / wy pliku, ale miała kilka wad.

Wiele metod nie zgłaszało wyjątków, gdy zawiodły, dlatego niemożliwe było uzyskanie użytecznego komunikatu o błędzie. Na przykład, jeśli usunięcie pliku nie powiedzie się, program otrzyma komunikat „niepowodzenie usunięcia”, ale nie będzie wiedział, czy to dlatego, że plik nie istnieje, użytkownik nie miał uprawnień lub wystąpił inny problem.

Metoda zmiany nazwy nie działała konsekwentnie na różnych platformach. Nie było rzeczywistego wsparcia dla dowiązań symbolicznych.

Potrzebna była większa obsługa metadanych, takich jak uprawnienia do pliku, właściciel pliku i inne atrybuty bezpieczeństwa.

Dostęp do metadanych pliku był nieefektywny.

Wiele metod File nie skalowało się. Żądanie dużej listy katalogów przez serwer może spowodować zawieszenie się. Duże katalogi mogą również powodować problemy z zasobami pamięci, powodując odmowę usługi.

Nie było możliwe napisanie wiarygodnego kodu, który mógłby rekurencyjnie chodzić po drzewie plików i odpowiednio reagować, jeśli były okrągłe dowiązania symboliczne.

Przy tak wielu wadach java.io.File, tak naprawdę nie potrzebujemy powodu, aby używać tej klasy do nowych prac.
Nawet w przypadku użycia starszego kodu java.io.FileOracle daje wskazówki do użycia Path.

Być może masz starszy kod, który używa java.io.File i chciałbyś skorzystać z funkcjonalności java.nio.file.Path przy minimalnym wpływie na Twój kod.

Klasa java.io.File udostępnia metodę toPath, która konwertuje instancję File w starym stylu na instancję java.nio.file.Path w następujący sposób:

Path input = file.toPath();

Następnie możesz skorzystać z bogatego zestawu funkcji dostępnych dla klasy Path.

Załóżmy na przykład, że masz kod, który usunął plik:

file.delete();

Możesz zmodyfikować ten kod, aby użyć metody Files.delete w następujący sposób:

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

Tak, ale wiele istniejących interfejsów API, w tym standardowe interfejsy API Java7, nadal działa tylko z Filetypem.

Plik Java.io.File nie jest przestarzały. Tak, java.nio.file.Path jest lepszy, ale dopóki jest mnóstwo programów i podręczników korzystających z Java.io.File, choćby ze względów starszych, nie należy go uważać za przestarzały, jest zbyt ważny. Takie postępowanie byłoby po prostu rzuceniem klucza w dzieło bez żadnego zysku. Na przykład struktura systemu Android używa pliku do niektórych podstawowych funkcji obsługi plików, wiele innych rzeczy robi.

Czy w przypadku nowych aplikacji napisanych w Javie 7 istnieje jakiś powód do używania obiektu java.io.File, czy możemy uznać go za przestarzały?

To trochę jak powiedzenie: „czy Napoleon powinien najechać Rosję, czy te brukselki naprawdę są smaczne?”

Co do drugiej części pytania, można rzeczywiście uznać je za przestarzałe. Od stycznia 2018 r. Nie jest przestarzałe. Ale nic nie stoi na przeszkodzie, abyś to rozważył . Nie da się powiedzieć, czy zapewni ci to jakąś przewagę w tym życiu, czy w następnym.