Para novos aplicativos escritos em Java 7, existe algum motivo para usar um java.io.File
objeto mais ou podemos considerá-lo obsoleto?
Eu acredito que um java.nio.file.Path
pode fazer tudo o que java.io.File
pode fazer e muito mais.
Para novos aplicativos escritos em Java 7, existe algum motivo para usar um java.io.File
objeto mais ou podemos considerá-lo obsoleto?
Eu acredito que um java.nio.file.Path
pode fazer tudo o que java.io.File
pode fazer e muito mais.
Respostas:
Longa história curta:
java.io.File
provavelmente nunca será descontinuado / não suportado. Dito isto, java.nio.file.Path
faz parte da java.nio.file
lib mais moderna e faz tudo o que java.io.File
pode, mas geralmente de uma maneira melhor e mais.
Para novos projetos, use Path
.
E se você precisar de um File
objeto para legado, basta chamar Path # toFile ()
Migrando do arquivo para o caminho
File
vez de Path
?
Path
pode ser modificado com mais facilidade para "adicionar filhos" resolve(...)
ou "subir um nível" com getParent()
etc., enquanto File
não pode. Essencialmente, quando você terminar de modificar o Path, frequentemente o converterá toFile()
para que possa ser enviado para métodos legados, como um FileInputStream
construtor.
podemos considerá-lo obsoleto?
Não, você não pode considerá-lo obsoleto, a menos e até que seja marcado no File
Javadoc.
java.io.File
ainda não foi removido nem preterido, e ainda não há nada no Javadoc que sugira que alguma dessas coisas aconteça.
Consulte este artigo para obter mais informações - http://www.oracle.com/technetwork/articles/javase/nio-139333.html
Basicamente, file.Path será o caminho a seguir a partir de agora, mas como é amplamente conhecido o pessoal de Java tende a manter a compatibilidade retroativa, acho que é por isso que o deixou.
Vou completar a resposta muito boa de @mmcrae
.
existe algum motivo para usar mais um objeto java.io.File ou podemos considerá-lo obsoleto?
As classes JDK raramente são preteridas.
Você pode ver na lista de preteridos da API do JDK 8 todas as classes preteridas desde o primeiro JDK.
Ele contém apenas uma pequena parte das classes que a documentação do Oracle e a comunidade Java desencorajam a usar.
java.util.Date
, java.util.Vector
, java.util.Hashtable
... que são classes com tantos defeitos não estão obsoletos.
Mas por que ?
Porque conceitualmente algo de deprecated
meios ainda existe, mas desencoraja o uso, pois certamente será removido.
Milhares de programas contam com essas classes mal projetadas.
Para essas classes, os desenvolvedores da API Java não emitem esse sinal.
A resposta de @EJP
é tão correta:
Não a menos e até que seja marcado no Javadoc.
Portanto, acho que sua pergunta faria mais sentido em seus termos:
"Como temos a escolha, devemos usar java.io.File
ou java.nio.file.Path
para novos desenvolvimentos e se a resposta for java.nio.file.Path
: você poderia facilmente tirar proveito dos java.io.File
projetos herdados java.io.File
?"
Eu acredito que um java.nio.file.Path pode fazer tudo o que um java.io.File pode fazer e muito mais.
Você tem a resposta.
Este tutorial da Oracle sobre E / S herdada confirma seu pensamento.
Antes do lançamento do Java SE 7, a
java.io.File
classe era o mecanismo usado para a E / S do arquivo, mas tinha várias desvantagens.Muitos métodos não lançaram exceções quando falharam; portanto, era impossível obter uma mensagem de erro útil. Por exemplo, se uma exclusão de arquivo falhasse, o programa receberia uma "falha de exclusão", mas não saberia se era porque o arquivo não existia, o usuário não tinha permissões ou havia algum outro problema.
O método de renomeação não funcionou consistentemente entre plataformas. Não havia suporte real para links simbólicos.
Foi desejado mais suporte para metadados, como permissões de arquivo, proprietário do arquivo e outros atributos de segurança.
O acesso aos metadados do arquivo foi ineficiente.
Muitos dos métodos de arquivo não foram dimensionados. Solicitar uma listagem de diretório grande em um servidor pode resultar em um travamento. Diretórios grandes também podem causar problemas de recursos de memória, resultando em uma negação de serviço.
Não foi possível escrever um código confiável que pudesse percorrer recursivamente uma árvore de arquivos e responder adequadamente se houvesse links simbólicos circulares.
Com tantas desvantagens java.io.File
, não precisamos realmente de nenhuma razão para usar essa classe para novos desenvolvimentos.
E mesmo para o uso de código legado java.io.File
, o Oracle fornece dicas de uso Path
.
Talvez você tenha um código legado que usa java.io.File e gostaria de aproveitar a funcionalidade java.nio.file.Path com um impacto mínimo no seu código.
A classe java.io.File fornece o método toPath, que converte uma instância de arquivo de estilo antigo em uma instância de java.nio.file.Path, da seguinte maneira:
Path input = file.toPath();
Você pode tirar proveito do rico conjunto de recursos disponíveis para a classe Path.
Por exemplo, suponha que você tenha algum código que excluiu um arquivo:
file.delete();
Você pode modificar esse código para usar o método Files.delete, da seguinte maneira:
Path fp = file.toPath();
Files.delete(fp);
Sim, mas muitas APIs existentes, incluindo as APIs padrão do Java7, ainda funcionam apenas com o File
tipo.
O Java.io.File não está obsoleto. Sim java.nio.file.Path é melhor, mas enquanto ainda houver muitos programas e livros de texto usando o Java.io.File, mesmo que por motivos legados, ele não deve ser considerado obsoleto, é muito importante. Fazer isso seria apenas jogar uma chave inglesa nos trabalhos, sem nenhum ganho geral. Por exemplo, a estrutura do Android usa File para alguns de seus recursos básicos de manipulação de arquivos, muitas outras coisas.
Path
era melhor. Ele perguntou se File
foi preterido.
Para novos aplicativos escritos em Java 7, existe algum motivo para usar um objeto java.io.File mais ou podemos considerá-lo obsoleto?
É como dizer: "Napoleão deveria invadir a Rússia, ou essas couves de Bruxelas são realmente saborosas?"
Quanto à segunda parte da pergunta, você pode realmente considerá-la obsoleta. Em janeiro de 2018, não foi preterido. Mas não há nada para impedi-lo de considerar isso. É impossível dizer se isso lhe proporcionará alguma vantagem nesta vida ou na próxima.
File
. Devo, sim ou não?"
File
qualquer maneira. Não vai morrer tão cedo.
it isn't deprecated. But there's nothing to stop you *considering* it so
RI MUITO.