Java: percorso vs file

Per le nuove applicazioni scritte in Java 7, c'è qualche motivo per utilizzare un java.io.Fileoggetto più o possiamo considerarlo deprecato?

Credo che si java.nio.file.Pathpossa fare tutto ciò che si java.io.Filepuò fare e altro ancora.

Per farla breve:

java.io.Filemolto probabilmente non sarà mai deprecato / non supportato. Detto questo, java.nio.file.Pathfa parte della più moderna java.nio.filelib e fa tutto il java.io.Filepossibile, ma generalmente in un modo migliore, e altro ancora.

Per i nuovi progetti, utilizzare Path.

E se hai mai bisogno di un Fileoggetto per legacy, basta chiamare Path # toFile ()

Migrazione da file a percorso

Questa pagina Oracle evidenzia le differenze e le mappe java.io.File functionalityajava.nio.file lib (including Path) functionality

Articolo di Janice J. Heiss e Sharon Zakhour, maggio 2009, che parla del file system NIO.2 in JDK 7

possiamo considerarlo deprecato?

No, non puoi considerarlo deprecato a meno che e fino a quando non è così contrassegnato nelFile Javadoc.

Consulta questo articolo per maggiori informazioni: http://www.oracle.com/technetwork/articles/javase/nio-139333.html

Fondamentalmente file.Path sarà la strada da percorrere da ora in poi, ma come è noto la gente Java tende a mantenere la retrocompatibilità, quindi immagino che sia per questo che l'hanno lasciata.

Completerò l'ottima risposta di @mmcrae.

c'è qualche motivo per usare un oggetto java.io.File o possiamo considerarlo deprecato?

Le classi JDK sono molto raramente deprecate. Nell'elenco dei deprecati dell'API JDK 8
è possibile visualizzare tutte le classi deprecate dal primo JDK. Contiene solo una piccola parte delle classi che la documentazione Oracle e la comunità Java sconsigliano di utilizzare. , , ... che sono classi con tanti difetti non sono deprecati. Ma perché ? Perché concettualmente qualcosa di mezzo è ancora lì, ma scoraggia da usare in quanto sarà sicuramente rimosso. Migliaia di programmi si basano su queste classi mal progettate. Per tali classi, gli sviluppatori dell'API Java non daranno tale segnale.

java.util.Datejava.util.Vectorjava.util.Hashtable

deprecated

La risposta @EJPè davvero giusta:

A meno che e fino a quando non è così segnato nel Javadoc.

Quindi, penso che la tua domanda avrebbe più senso nei suoi termini:
"Come abbiamo la scelta, dovremmo usare java.io.Fileo java.nio.file.Pathper nuovi sviluppi e se la risposta è java.nio.file.Path, potresti facilmente trarre vantaggio dai java.io.Fileprogetti legacy che usano java.io.File?"

Credo che un file java.nio.file.Path possa fare tutto ciò che un file java.io.File può fare e altro ancora.

Hai la risposta

Questo tutorial sull'oracolo dell'IO legacy conferma il tuo pensiero.

Prima della versione Java SE 7, il java.io.File classe era il meccanismo utilizzato per l'I / O dei file, ma presentava numerosi inconvenienti.

Molti metodi non generavano eccezioni quando fallivano, quindi era impossibile ottenere un utile messaggio di errore. Ad esempio, se la cancellazione di un file non è riuscita, il programma riceverà un "errore di eliminazione" ma non saprebbe se era perché il file non esisteva, l'utente non aveva le autorizzazioni o c'era qualche altro problema.

Il metodo di rinomina non ha funzionato in modo coerente su tutte le piattaforme. Non c'era un vero supporto per i collegamenti simbolici.

È stato richiesto un maggiore supporto per i metadati, come autorizzazioni per i file, proprietario del file e altri attributi di sicurezza.

L'accesso ai metadati dei file era inefficiente.

Molti dei metodi File non sono stati ridimensionati. La richiesta di un elenco di directory di grandi dimensioni su un server potrebbe provocare un blocco. Le directory di grandi dimensioni potrebbero anche causare problemi di risorse di memoria, con conseguente negazione del servizio.

Non è stato possibile scrivere un codice affidabile che potesse ricorrere in modo ricorsivo a un albero di file e rispondere in modo appropriato se esistessero collegamenti simbolici circolari.

Con così tanti inconvenienti java.io.File, non abbiamo davvero alcun motivo per usare questa classe per nuovi sviluppi.
E anche per l'utilizzo del codice legacy java.io.File, Oracle fornisce suggerimenti da utilizzare Path.

Forse hai un codice legacy che utilizza java.io.File e vorresti sfruttare la funzionalità java.nio.file.Path con un impatto minimo sul tuo codice.

La classe java.io.File fornisce il metodo toPath, che converte un'istanza di file di vecchio stile in un'istanza java.nio.file.Path, come segue:

Path input = file.toPath();

È quindi possibile sfruttare il ricco set di funzionalità disponibili per la classe Path.

Ad esempio, supponi di avere del codice che ha eliminato un file:

file.delete();

È possibile modificare questo codice per utilizzare il metodo Files.delete, come segue:

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

Sì, ma molte API esistenti, incluse le API standard di Java7, funzionano ancora solo con il Filetipo.

Java.io.File non è obsoleto. Sì, java.nio.file.Path è migliore, ma fintanto che ci sono ancora molti programmi e libri di testo che utilizzano Java.io.File, se non altro per motivi legacy, non dovrebbe essere considerato deprecato, è troppo importante. Farlo significherebbe semplicemente lanciare una chiave inglese per non ottenere alcun vantaggio. Ad esempio, il framework Android utilizza File per alcune delle sue funzionalità di base per la gestione dei file, come fanno molte altre cose.

Per le nuove applicazioni scritte in Java 7, c'è qualche motivo per usare più un oggetto java.io.File o possiamo considerarlo obsoleto?

È un po 'come dire: "Napoleone dovrebbe invadere la Russia, o questi cavoletti di Bruxelles sono davvero gustosi?"

Per quanto riguarda la seconda parte della domanda, puoi davvero considerarla deprecata. A partire da gennaio 2018, non è obsoleto. Ma non c'è nulla che possa impedirti di considerarlo così. È impossibile dire se ciò ti procurerà qualche vantaggio in questa vita o in quella successiva.