Java NIO Files richtig nutzen - Dateien sicher verarbeiten

Eine Datei zu lesen, zu verschieben oder sicher zu löschen klingt zunächst nach einer kleinen Aufgabe. In echten Java-Anwendungen entscheiden jedoch Pfade, Zeichencodierung, Berechtigungen und der Umgang mit großen Verzeichnissen darüber, ob der Code zuverlässig läuft. Ich zeige, wie die moderne NIO-API mit Path und Files funktioniert, wann welche Methode sinnvoll ist und welche Fehler in der Praxis besonders häufig auftreten.

Java NIO Files in der Praxis verstehen

Die moderne Dateiverarbeitung liegt im Paket java.nio.file, das mit Java 7 eingeführt wurde. Der zentrale Unterschied zur älteren API ist die klare Trennung zwischen einem Pfadobjekt und der Operation selbst. Ich arbeite deshalb fast immer mit Path für die Adresse und Files für Lesen, Schreiben, Kopieren oder Löschen.

import java.nio.file.Path;
import java.nio.file.Files;

Path datei = Path.of("daten", "bericht.txt");

if (Files.exists(datei)) {
    System.out.println("Datei gefunden: " + datei.toAbsolutePath());
}

Path.of() setzt die einzelnen Bestandteile plattformgerecht zusammen. Unter Windows entsteht daraus beispielsweise ein passender Windows-Pfad, während Linux und macOS ihre eigenen Trennzeichen verwenden. Harte Zeichenketten wie "C:\\daten\\bericht.txt" sind deshalb meist eine schlechte Idee, besonders wenn die Anwendung auf mehreren Betriebssystemen laufen soll.

Im Vergleich zu java.io.File bietet Path deutlich bessere Methoden für Verkettung, Normalisierung und relative Pfade. Die alte Klasse ist nicht unbrauchbar, aber für neue Anwendungen würde ich die NIO-API als Standard setzen.

Dateien lesen und schreiben ohne unnötige Komplexität

Für Konfigurationsdateien, kleine JSON-Dokumente oder kurze Protokolle sind readString() und writeString() angenehm direkt. Beide Methoden verwenden standardmäßig UTF-8, trotzdem gebe ich die Zeichencodierung im produktiven Code lieber ausdrücklich an. So bleibt das Verhalten auch bei späteren Änderungen eindeutig.

import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

Path datei = Path.of("daten", "notiz.txt");

Files.createDirectories(datei.getParent());

Files.writeString(
    datei,
    "Erste Zeile\nZweite Zeile\n",
    StandardCharsets.UTF_8,
    StandardOpenOption.CREATE,
    StandardOpenOption.TRUNCATE_EXISTING,
    StandardOpenOption.WRITE
);

String inhalt = Files.readString(datei, StandardCharsets.UTF_8);
System.out.println(inhalt);

Die Option TRUNCATE_EXISTING leert eine vorhandene Datei vor dem Schreiben. Soll neuer Inhalt angehängt werden, verwende ich stattdessen APPEND. Ohne eine bewusste Entscheidung kann eine harmlose Schreiboperation sonst bestehende Daten überschreiben.

Files.writeString(
    datei,
    "Zusätzlicher Eintrag\n",
    StandardCharsets.UTF_8,
    StandardOpenOption.CREATE,
    StandardOpenOption.APPEND
);

Wann ein Stream die bessere Wahl ist

readString() lädt den gesamten Inhalt in einen String. Bei einer Datei mit wenigen Kilobyte ist das praktisch egal. Bei mehreren hundert Megabyte kann diese Abkürzung jedoch zu hohem Speicherverbrauch oder sogar zu einem OutOfMemoryError führen.

try (var zeilen = Files.lines(datei, StandardCharsets.UTF_8)) {
    zeilen.filter(zeile -> zeile.contains("WARN"))
          .forEach(System.out::println);
}

Ich verwende Files.lines(), wenn nur einzelne Zeilen verarbeitet werden müssen. Der Stream liest die Daten schrittweise und sollte immer in einem Try-with-resources-Block stehen, damit der Dateideskriptor zuverlässig geschlossen wird.

Kopieren, verschieben und löschen mit klaren Regeln

Die Methoden copy(), move() und deleteIfExists() decken den größten Teil gewöhnlicher Dateiabläufe ab. Entscheidend ist weniger der Methodenname als die Frage, was passieren soll, wenn die Zieldatei bereits existiert.

import java.nio.file.Path;
import java.nio.file.Files;
import java.nio.file.StandardCopyOption;

Path quelle = Path.of("eingang", "rechnung.pdf");
Path ziel = Path.of("archiv", "rechnung.pdf");

Files.createDirectories(ziel.getParent());

Files.copy(
    quelle,
    ziel,
    StandardCopyOption.REPLACE_EXISTING
);

Files.deleteIfExists(quelle);

Dieser Ablauf imitiert ein Verschieben, ist aber nicht immer gleichwertig zu Files.move(). Bei unterschiedlichen Dateisystemen kann ein Move intern als Kopieren mit anschließendem Löschen ausgeführt werden. Für einen normalen Ortswechsel innerhalb desselben Dateisystems ist move() meist die passendere und klarere Wahl.

Files.move(
    quelle,
    ziel,
    StandardCopyOption.REPLACE_EXISTING
);

Wenn ein Vorgang entweder vollständig sichtbar werden oder gar nicht stattfinden soll, kann ATOMIC_MOVE sinnvoll sein. Diese Zusicherung hängt jedoch vom verwendeten Dateisystem und dessen Provider ab. Ich behandle atomare Verschiebungen deshalb als mögliche Optimierung, nicht als Garantie für jede Umgebung.

Existenz prüfen oder direkt handeln

Ein häufiger Fehler ist eine Prüfung mit Files.exists(), gefolgt von einer späteren Operation. Zwischen beiden Aufrufen kann sich der Zustand ändern, etwa durch einen anderen Prozess. In vielen Fällen ist es robuster, die Operation direkt auszuführen und die passende Ausnahme zu behandeln.

try {
    Files.delete(datei);
} catch (java.nio.file.NoSuchFileException e) {
    System.out.println("Die Datei wurde bereits entfernt.");
} catch (java.io.IOException e) {
    System.err.println("Löschen nicht möglich: " + e.getMessage());
}

deleteIfExists() ist praktisch, wenn das Fehlen der Datei kein Fehler sein soll. Für sicherheitskritische Abläufe reicht die Methode allein aber nicht aus, weil Berechtigungen, symbolische Links und konkurrierende Prozesse weiterhin eine Rolle spielen.

Verzeichnisse effizient durchsuchen

Für ein einzelnes Verzeichnis verwende ich Files.list(). Die Methode liefert einen Stream der direkten Einträge. Unterverzeichnisse werden dabei nicht automatisch durchsucht, was für Upload-Ordner oder einfache Importverzeichnisse oft genau richtig ist.

Path ordner = Path.of("eingang");

try (var eintraege = Files.list(ordner)) {
    eintraege.filter(Files::isRegularFile)
             .filter(pfad -> pfad.toString().endsWith(".csv"))
             .forEach(System.out::println);
}

Für eine vollständige Verzeichnisstruktur ist Files.walk() geeigneter. Mit maxDepth lässt sich verhindern, dass ein unerwartet tiefes Verzeichnis den Prozess unnötig belastet.

Path root = Path.of("projekt");

try (var dateien = Files.walk(root, 5)) {
    dateien.filter(Files::isRegularFile)
           .filter(pfad -> pfad.getFileName().toString().endsWith(".log"))
           .forEach(pfad -> System.out.println(pfad.toAbsolutePath()));
}

Bei sehr großen Verzeichnisbäumen sollte ich zusätzlich überlegen, ob wirklich jede Datei benötigt wird. Filter möglichst früh, begrenze die Tiefe und vermeide es, sämtliche Ergebnisse erst in eine Liste zu sammeln. Das spart Speicher und Laufzeit, ohne die Lesbarkeit zu verschlechtern.

Wenn die Dateinamen nicht ausreichen

Mit Files.getLastModifiedTime(), Files.size() und Files.readAttributes() lassen sich Dateien nach Alter, Größe oder weiteren Attributen filtern. Für einen Importprozess kann das beispielsweise bedeuten, dass nur Dateien verarbeitet werden, die älter als fünf Minuten sind. So sinkt das Risiko, eine Datei zu lesen, während ein anderer Prozess noch hineinschreibt.

Fehler, Sicherheit und Performance von Anfang an einplanen

Fast jede Dateioperation kann eine IOException auslösen. Typische Ursachen sind fehlende Berechtigungen, nicht vorhandene Elternverzeichnisse, gesperrte Dateien, ungültige Pfade oder ein volles Laufwerk. Ich gebe diese Ausnahme nicht einfach mit einer allgemeinen Fehlermeldung aus, sondern erfasse möglichst den betroffenen Pfad und die konkrete Operation.

try {
    String text = Files.readString(datei, StandardCharsets.UTF_8);
    verarbeite(text);
} catch (java.nio.file.NoSuchFileException e) {
    throw new IllegalStateException("Eingabedatei fehlt: " + datei, e);
} catch (java.nio.file.AccessDeniedException e) {
    throw new IllegalStateException("Kein Zugriff auf: " + datei, e);
} catch (java.io.IOException e) {
    throw new IllegalStateException("Datei konnte nicht gelesen werden: " + datei, e);
}

Pfade aus Benutzereingaben absichern

Kommt ein Dateiname aus einer HTTP-Anfrage, einem Formular oder einer Importdatei, darf er nicht ungeprüft mit einem Basisverzeichnis verbunden werden. Sonst kann ein Angreifer mit Sequenzen wie ../ auf Dateien außerhalb des vorgesehenen Ordners zugreifen.

Path basis = Path.of("/srv/app/uploads").toAbsolutePath().normalize();
Path angefordert = basis.resolve(dateiname).normalize();

if (!angefordert.startsWith(basis)) {
    throw new SecurityException("Ungültiger Dateipfad");
}

Diese Prüfung ist ein wichtiger Anfang, aber kein vollständiges Sicherheitskonzept. Bei symbolischen Links kann der tatsächlich aufgelöste Pfad weiterhin außerhalb des Basisordners liegen. Für sensible Anwendungen prüfe ich deshalb zusätzlich die reale Pfadauflösung und beschränke Dateinamen auf erlaubte Zeichen und Endungen.

Zeichencodierung und Ressourcen nicht dem Zufall überlassen

UTF-8 ist für neue Anwendungen meist die vernünftige Wahl, besonders bei deutschen Umlauten und internationalem Inhalt. Wer die Codierung nicht explizit festlegt, riskiert Unterschiede zwischen Entwicklungsrechner, Container und Produktionsserver.

Bei Streams wie Files.list(), Files.walk() und Files.lines() ist das Schließen besonders wichtig. Ein vergessenes Ressourcenmanagement kann bei vielen Dateien dazu führen, dass Dateideskriptoren ausgehen, obwohl der Code auf den ersten Blick funktioniert.

Lesen Sie auch: Moderne Softwareentwicklung - was in der Praxis wirklich trägt

Die passende Methode nach Dateigröße

Ein bewährtes Muster für neue Java-Projekte

Für einfache Anwendungen beginne ich mit Path.of(), explizitem UTF-8 und einer klaren Fehlerbehandlung. Erst wenn Dateien groß werden oder viele Einträge verarbeitet werden, wechsle ich zu Streams, Channels oder einer spezialisierten Importlogik.

• Pfade mit Path zusammensetzen, niemals mit manuellen Trennzeichen.
• Elternverzeichnisse vor dem Schreiben mit createDirectories() anlegen.
• Bei jedem Schreibvorgang bewusst zwischen Überschreiben und Anhängen entscheiden.
• Streams immer mit Try-with-resources schließen.
• Benutzereingaben normalisieren und auf das erlaubte Basisverzeichnis begrenzen.
• Bei großen Dateien keine Methode verwenden, die den gesamten Inhalt in den Speicher lädt.

Die NIO-API wirkt zunächst umfangreich, wird aber schnell überschaubar, wenn man die Rollen trennt. Path beschreibt den Ort, Files erledigt die Operation und die Open- sowie Copy-Optionen legen fest, wie genau sie ausgeführt wird.

Warum kleine Entscheidungen bei Dateioperationen große Folgen haben

Die meisten Probleme entstehen nicht durch fehlende Methoden, sondern durch unklare Annahmen. Wer Zeichencodierung, Dateigröße, Überschreibverhalten und Pfadherkunft früh festlegt, erhält Code, der auch außerhalb der lokalen Entwicklungsumgebung zuverlässig bleibt.

Mein pragmatischer Standard lautet deshalb Path, Files, UTF-8 und explizites Ressourcenmanagement. Damit lassen sich die üblichen Dateiabläufe sauber lösen, während komplexere Fälle gezielt mit Streams, Attributen oder Channels erweitert werden können.