¿Alternativa a File.deleteOnExit() en Java NIO?

Java IO tiene Archivo.eliminarAlSalir(), que es un método que elimina el archivo al que se llama durante la finalización normal de la JVM. Descubrí que esto es muy útil para limpiar archivos temporales, especialmente durante las pruebas unitarias.

Sin embargo, no veo un método con el mismo nombre en Java NIO archivos clase. Soy consciente de que puedo hacer path.toFile().deleteOnExit()pero me gustaría saber si hay una alternativa usando NIO.

¿Hay alguna alternativa? Si no, ¿por qué no hay uno?

Respuesta corta

No puede eliminar archivos arbitrarios en Java NIO, pero puede usar el StandardOpenOption.DELETE_ON_CLOSE al abrir una nueva transmisión, que eliminará el archivo tan pronto como se cierre la transmisión, ya sea llamando .close() (incluso desde una declaración de prueba con recursos) o la terminación de JVM. Por ejemplo:

Files.newOutputStream(Paths.get("Foo.tmp"), StandardOpenOption.DELETE_ON_CLOSE);

Respuesta larga

Después de investigar mucho, descubrí que Java NIO hace tiene una forma de eliminar al salir, pero lo aborda de una manera diferente que Java I/O.

En primer lugar, el Javadoc para Files.createTempFile() describe tres formas de eliminar archivos:

Donde se usa como archivos de trabajo [sic]el archivo resultante se puede abrir usando el DELETE_ON_CLOSE para que el archivo se elimine cuando se invoque el método de cierre apropiado. Alternativamente, un apagado-ganchoo el File.deleteOnExit() Se puede utilizar un mecanismo para eliminar el archivo automáticamente.

La última elección, File.deleteOnExit() es, por supuesto, un método de E/S de Java, que estamos tratando de evitar. Un gancho de apagado es lo que sucede detrás de escena cuando llama al método mencionado anteriormente. Pero el DELETE_ON_CLOSE La opción es Java NIO puro.

En lugar de eliminar archivos arbitrarios, Java NIO asume que solo está interesado en eliminar los archivos que realmente está abriendo. Por lo tanto, los métodos que crean una nueva secuencia como Files.newOutputStream() opcionalmente puede tomar varios OpenOptionsdonde puede ingresar StandardOpenOption.DELETE_ON_CLOSE. Lo que hace es eliminar el archivo tan pronto como se cierra la transmisión (ya sea mediante una llamada a .close() o la salida de JVM).

Por ejemplo:

Files.newOutputStream(Paths.get("Foo.tmp"), StandardOpenOption.DELETE_ON_CLOSE);

… eliminará el archivo asociado con la transmisión cuando se cierre la transmisión, ya sea por una llamada explícita a .close()el flujo se cierra como parte de una declaración de prueba con recursos o la JVM finaliza.

Actualizar: En algunos sistemas operativos como Linux, StandardOpenOption.DELETE_ON_CLOSE se elimina tan pronto como se crea el OutputStream. Si todo lo que necesita es un OutputStream, todavía puede estar bien. Consulte DELETE_ON_CLOSE elimina archivos antes de cerrar en Linux para obtener más información.

Entonces, Java NIO agrega una nueva funcionalidad sobre Java I/O en la que puede eliminar un archivo al cerrar una secuencia. Si esa es una alternativa lo suficientemente buena para eliminar durante la salida de JVM, puede hacerlo en Java NIO puro. Si no, tendrá que confiar en las E/S de Java File.deleteOnExit() o un gancho de apagado para eliminar el archivo.

Entre bastidores, File.deleteOnExit() simplemente creará un shutdown hook a través de Runtime.addShutdownHook().

Luego, puedes hacer lo mismo con NIO:

Runtime.getRuntime().addShutdownHook(new Thread() {
  public void run() {
    Path path = ...;

    Files.delete(path);
  }
});

No recomendaría calzarse StandardOpenOption.DELETE_ON_CLOSE en un reemplazo para File.deleteOnExit(). Como menciona la documentación, no pretende ser de propósito general, ni es probable que funcione correctamente fuera de los casos triviales.

DELETE_ON_CLOSE, como su nombre lo indica, está diseñado para eliminar un archivo una vez que se cierra para limpiar inmediatamente un recurso que ya no se necesita. la documentación para Files.createTempFile() es igualmente claro en este punto, DELETE_ON_CLOSE se puede usar para “archivos de trabajo” que solo se necesitan mientras el archivo está abierto.

El Files.createTempFile() los documentos sugieren directamente escribir su propio enlace de apagado o simplemente continuar usando File.deleteOnExit(). A pesar de su deseo de usar NIO, no hay nada intrínsecamente malo en usar File.deleteOnExit() si solo está trabajando con el sistema de archivos local. Si no está usando (o no está seguro de estar usando) el sistema de archivos local y, por lo tanto, no poder usar File.deleteOnExit() es lo suficientemente sencillo como para escribir su propio gancho de apagado como que File hace:

public final class DeletePathsAtShutdown {
  private static LinkedHashSet<Path> files = new LinkedHashSet<>();

  static {
    Runtime.getRuntime().addShutdownHook(
        new Thread(DeletePathsAtShutdown::shutdownHook));
  }

  private static void shutdownHook() {
    LinkedHashSet<Path> local;
    synchronized {
      local = paths;
      paths = null;
    }

    ArrayList<Path> toBeDeleted = new ArrayList<>(theFiles);
    Collections.reverse(toBeDeleted);
    for (Path p : toBeDeleted) {
      try {
        Files.delete(p);
      } catch (IOException | RuntimeException e) {
        // do nothing - best-effort
      }
    }
  }

  public static synchronized void register(Path p) {
    if (paths == null) {
      throw new IllegalStateException("ShutdownHook already in progress.");
    }
    paths.add(p);
  }
}

Claro, sería bueno si NIO incluyera un gancho de apagado similar listo para usar, pero su ausencia no es razón para usar la herramienta incorrecta para el trabajo. También puede agregar más funciones a DeletePathsAtShutdowncomo una remove() función, o soporte para la eliminación de directorios.