Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger. 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 18 Einführung in Dateien und Datenströme
Pfeil 18.1 API für Dateien, Verzeichnisse und Verzeichnissysteme
Pfeil 18.1.1 java.io-Paket mit File-Klasse
Pfeil 18.1.2 NIO.2 und java.nio-Paket
Pfeil 18.2 Datei und Verzeichnis
Pfeil 18.2.1 FileSystem und Path
Pfeil 18.2.2 Die Utility-Klasse Files
Pfeil 18.2.3 Dateien kopieren und verschieben
Pfeil 18.2.4 Neue Dateien, Verzeichnisse, symbolische Verknüpfungen anlegen und löschen
Pfeil 18.3 Dateien mit wahlfreiem Zugriff
Pfeil 18.3.1 Ein RandomAccessFile zum Lesen und Schreiben öffnen
Pfeil 18.3.2 Aus dem RandomAccessFile lesen
Pfeil 18.3.3 Schreiben mit RandomAccessFile
Pfeil 18.3.4 Die Länge des RandomAccessFile
Pfeil 18.3.5 Hin und her in der Datei
Pfeil 18.4 Stream-Klassen für Bytes und Zeichen
Pfeil 18.4.1 Lesen aus Dateien und Schreiben in Dateien
Pfeil 18.4.2 Byteorientierte Datenströme über Files beziehen
Pfeil 18.4.3 Zeichenorientierte Datenströme über Files beziehen
Pfeil 18.4.4 Funktion von OpenOption bei den Files.newXXX(…)-Methoden
Pfeil 18.4.5 Ressourcen aus dem Klassenpfad und aus JAR-Archiven laden
Pfeil 18.4.6 Die Schnittstellen Closeable, AutoCloseable und Flushable
Pfeil 18.5 Basisklassen für die Ein-/Ausgabe
Pfeil 18.5.1 Die abstrakten Basisklassen
Pfeil 18.5.2 Übersicht über Ein-/Ausgabeklassen
Pfeil 18.5.3 Die abstrakte Basisklasse OutputStream
Pfeil 18.5.4 Die abstrakte Basisklasse InputStream
Pfeil 18.5.5 Die abstrakte Basisklasse Writer
Pfeil 18.5.6 Die abstrakte Basisklasse Reader
Pfeil 18.6 Datenströme filtern und verketten
Pfeil 18.6.1 Streams als Filter verketten (verschachteln)
Pfeil 18.6.2 Gepufferte Ausgaben mit BufferedWriter und BufferedOutputStream
Pfeil 18.6.3 Gepufferte Eingaben mit BufferedReader/BufferedInputStream
Pfeil 18.7 Vermittler zwischen Byte-Streams und Unicode-Strömen
Pfeil 18.7.1 Datenkonvertierung durch den OutputStreamWriter
Pfeil 18.7.2 Automatische Konvertierungen mit dem InputStreamReader
Pfeil 18.8 Zum Weiterlesen
 

Zum Seitenanfang

18.2Datei und Verzeichnis Zur vorigen ÜberschriftZur nächsten Überschrift

Im Zentrum von NIO.2 stehen die Typen FileSystem und Path:

  • FileSystem beschreibt ein Datensystem und ist eine abstrakte Klasse. Es wird von konkreten Dateisystemen, wie dem lokalen Dateisystem oder einem ZIP-Archiv, realisiert. Um an das aktuelle Dateisystem zu kommen, deklariert die Klasse FileSystems eine statische Methode: FileSystems.getDefault().

  • Path repräsentiert einen Pfad zu einer Datei oder einem Verzeichnis, wobei die Pfadangaben relativ oder absolut sein können. Die Methoden erinnern ein wenig an die alte Klasse File, doch der große Unterschied ist, dass File selbst die Datei oder das Verzeichnis repräsentiert und Abfragemethoden wie isDirectory() oder lastModified() deklariert, während Path nur den Pfad repräsentiert und nur pfadbezogene Methoden anbietet. Modifikationsmethoden gehören nicht dazu; dazu dienen Extratypen wie BasicFileAttributes für Attribute.

 

Zum Seitenanfang

18.2.1FileSystem und Path Zur vorigen ÜberschriftZur nächsten Überschrift

Ein Path-Objekt lässt sich nicht wie File über einen Konstruktor aufbauen, da die Klasse abstrakt ist. File und Path haben aber dennoch einiges gemeinsam, etwa dass sie immutable sind. Das FileSystem-Objekt bietet die entsprechende Methode getPath(…), und ein FileSystem wird über eine Fabrikmethode von FileSystems erfragt.

[zB]Beispiel

Baue ein Path-Objekt auf:

FileSystem fs = FileSystems.getDefault();

Path p = fs.getPath( "C:/Windows/Fonts/" );

Da der Ausdruck FileSystems.getDefault().getPath(…) etwas unhandlich ist, existiert eine Utility-Klasse, und der Aufruf von Paths.get() kürzt das Ganze ab. Auch aus einem File-Objekt lässt sich mit toPath() ein Path ableiten. Wir werden die Vereinfachung mit Paths.get(…) im Folgenden nutzen.

final class java.nio.file.Paths
  • static Path get(String first, String... more)

    Erzeuge einen Pfad aus Segmenten. Wenn etwa »\« der Separator ist, dann ist Paths.get("a", "b", "c") gleich Paths.get("a\\b\\c").

  • static Path get(URI uri)

    Erzeugt einen Pfad aus einem URI.

Jedes Path-Objekt hat eine Methode getFileSystem(), um wieder an das FileSystem zu kommen.

Abhängigkeiten der Klassen Paths und Path

Abbildung 18.1Abhängigkeiten der Klassen Paths und Path

[»]Hinweis

Der Pfad-String darf unter Java kein \u0000 enthalten, andernfalls gibt es eine Ausnahme. So führt Paths.get("my.php\u0000.jpg") zur Ausnahme »java.nio.file.InvalidPathException: Illegal char < > at index 6: my.php«. Das ist ein wichtiges Sicherheitsmerkmal, um zum Beispiel einen Webserver zu schützen, keine falschen Dateien anzunehmen. Der Dateiname sieht über "my.php\u0000.jpg".endsWith(".jpg") wie eine JPG-Datei aus, aber würde alles nach dem Null-String abgeschnitten (was einige Dateisysteme machen), wäre plötzlich eine Datei my.php angelegt.

Path-Eigenschaften erfragen

Die Path-Klasse deklariert diverse getXXX(…)-Methoden (und eine isAbsolute()-Methode), die eine gewisse Ähnlichkeit mit den Methoden aus File haben. Ein paar Beispiele zur Anwendung:

Listing 18.1com/tutego/insel/nio2/FileSystemPathFileDemo1.java, main()

Path p = Paths.get( "C:/Windows/Fonts/" );

System.out.println( p.toString() ); // C:\Windows\Fonts

System.out.println( p.isAbsolute() ); // true

System.out.println( p.getRoot() ); // C:\

System.out.println( p.getParent() ); // Fonts

System.out.println( p.getNameCount() ); // 2

System.out.println( p.getName(p.getNameCount()-1) ); // Fonts

Methoden wie getPath(), getRoot() und getParent() liefern alle wiederum Path-Objekte aus den Bestandteilen eines gegebenen Pfades. Es gibt drei Methoden, das Ergebnis nicht als Path weiterzuverarbeiten: toString() liefert eine String-Repräsentation, die Methode toUri() einen URI und toFile() ein traditionelles File-Objekt.

Klassendiagramm von Path

Abbildung 18.2Klassendiagramm von Path

Dadurch, dass Path eine hierarchische Liste von Namen für den Pfad speichert, lässt sich jedes Segment des Pfades erfragen; das ist die Aufgabe von getName(int n), das wiederum einen Path liefert. Die Methode subpath(int beginIndex, int endIndex) liefert einen Path mit den Segmenten des angegebenen Bereichs. Path implementiert die Iterable-Schnittstelle, was eine Methode iterator() vorschreibt – das wiederum bedeutet, dass Path rechts vom Doppelpunkt im erweiterten for auftauchen kann.

Praktisch sind die Prüfmethoden startsWith(Path other) und endsWith(Path other), die feststellen, ob der Pfad mit einem bestimmten anderen Pfad beginnt oder endet. Aus Object wird equals(…) überschrieben. Da Path die Schnittstelle Comparable<Path> realisiert, wird zudem compareTo(Path) implementiert. Die Methode equals(…) löst die Pfade nicht auf, sondern betrachtet nur den Namen; die statische Methode isSameFile(Path, Path) der Klasse Files macht diesen Test und löst relative Bezüge auf. Neben equals(…) überschreibt Path auch hashCode().

interface java.nio.file.Path

extends Comparable<Path>, Iterable<Path>, Watchable
  • String toString()

  • File toFile()

  • URI toUri()

  • Path getFileName()

  • Path getParent()

  • Path getRoot()

  • boolean isAbsolute()

  • int getNameCount()

  • Path getName(int index)

  • Iterator<Path> iterator()

  • Path subpath(int beginIndex, int endIndex)

  • boolean endsWith(Path other)

  • boolean endsWith(String other)

  • boolean startsWith(Path other)

  • boolean startsWith(String other)

  • boolean equals(Object other)

  • int compareTo(Path other)

  • int hashCode()

Vererbungsbeziehung von Path

Abbildung 18.3Vererbungsbeziehung von Path

[»]Hinweis

Die Methode getFileName() liefert keinen String, sondern ein Path-Objekt nur mit dem Dateinamen. Daher führt path.getFileName().endsWith(".xml") zum Testen, ob ein Dateiname auf ».xml« endet, nicht zum Ziel, sondern nur path.getFileName().toString().endsWith(".xml"). Das kann für Umsteiger schnell zu einer Falle werden.

Neue Pfade aufbauen

Die Methode resolve(…) baut neue Pfade zusammen und akzeptiert die Parametertypen String und Path.

[zB]Beispiel

Hänge das Benutzerverzeichnis mit dem Bilderverzeichnis zusammen:

Path picturePath = Paths.get( System.getProperty("user.home") )

.resolve( "Pictures" )

.resolve( "Cora" );

System.out.println( picturePath ); // z. B. C:\Users\Chris\Pictures\Cora

Eine interessante Methode ist auch relativize(Path) – sie liefert aus einer Basisangabe einen relativen Pfad, der zu einem anderen Pfad führt.

[zB]Beispiel

Von c:\Windows\Fonts nach c:\Windows\Cursors führt der relative Pfad ..\Cursors:

System.out.println( Paths.get( "C:\Windows\Fonts" )

.relativize( Paths.get("C:\Windows\Cursors") )

); // ..\Cursors
interface java.nio.file.Path

extends Comparable<Path>, Iterable<Path>, Watchable
  • Path relativize(Path other)

  • Path resolve(Path other)

  • Path resolve(String other)

  • Path resolveSibling(Path other)

  • Path resolveSibling(String other)

Normalisierung und Pfadauflösung

Genauso wie die File-Klasse symbolisiert die Path-Klasse einen Pfad, aber dieser muss nicht auf eine konkrete Datei oder ein konkretes Verzeichnis zeigen. Daher liefern die vorgestellten Methoden lediglich Informationen, die sich aus dem vorgegebenen Namen erschließen lassen, ohne auf das Dateisystem zurückzugreifen. Bei relativen Pfaden liefern die Anfragemethoden daher wenig Spannendes:

Listing 18.2com/tutego/insel/nio2/FileSystemPathFileDemo2.java, main()

Path p = Paths.get( "../.." );

System.out.println( p.toString() ); // ..\..

System.out.println( p.isAbsolute() ); // false

System.out.println( p.getRoot() ); // null

System.out.println( p.getParent() ); // ..

System.out.println( p.getNameCount() ); // 2

System.out.println( p.getName(p.getNameCount()-1) ); // ..

Um ein wenig Ordnung in relative Pfadangaben zu bringen, bietet die Path-Klasse die Methode normalize(), die ohne Zugriff auf das Dateisystem die Bezüge ».« und »..« entfernt.

Zum Auflösen der relativen Adressierung mit Zugriff auf das Dateisystem bietet die Path-Klasse die beiden Methoden toAbsolutePath() bzw. toRealPath(…) an.

Listing 18.3com/tutego/insel/nio2/RealAndAbsolutePath.java, main()

Path p2 = Paths.get( "../.." );

System.out.println( p2.toAbsolutePath() );

// C:\Users\Christian\Documents\Insel\programme\2_06_Files\..\..

try {

System.out.println( p2.toRealPath( LinkOption.NOFOLLOW_LINKS ) );

// C:\Users\Christian\Documents\Insel

}

catch ( IOException e ) { e.printStackTrace(); }

Die erste Methode, toAbsolutePath(), normalisiert nicht, sondern löst einfach nur den relativen Pfad in einen absoluten Pfad auf. Die Auflösung vom ../.. erledigt toRealPath(LinkOption…), wobei das (optionale) Argument ausdrückt, ob Verknüpfungen verfolgt werden sollen oder nicht.

[zB]Beispiel

Die Methode toRealPath(…) löst eine Ausnahme aus, wenn eine Auflösung eines Pfades zu einer Datei versucht wird, die nicht existiert. So führt zum Beispiel

Paths.get( "../0x" ).toRealPath( true )

zur »java.nio.file.NoSuchFileException: C:\Users\Chris\0x«. Paths.get( "../0x" ).toAbsolutePath() führt zu keinem Fehler.

interface java.nio.file.Path

extends Comparable<Path>, Iterable<Path>, Watchable
  • Path normalize()

  • Path toAbsolutePath()

  • Path toRealPath(LinkOption... options)

Es gibt noch zwei register(…)-Methoden in Path, doch die haben etwas mit dem Anmelden eines Horchers zu tun, der auf Änderungen im Dateisystem reagiert.

 

Zum Seitenanfang

18.2.2Die Utility-Klasse Files Zur vorigen ÜberschriftZur nächsten Überschrift

Da die Klasse Path nur Pfade, aber keine Dateiinformationen wie die Länge oder Änderungszeit repräsentiert, und da Path auch keine Möglichkeit bietet, Dateien anzulegen und zu löschen, übernimmt die Klasse Files diese Aufgaben.

Einfaches Einlesen und Schreiben von Dateien

Mit den Methoden readAllBytes(…), readAllLines(…), lines(…) und write(…) kann Files einfach einen Dateiinhalt einlesen oder Strings bzw. ein Byte-Feld schreiben.

Listing 18.4com/tutego/insel/nio2/ListAllLines.java, main()

URI uri = ListAllLines.class.getResource( "/lyrics.txt" ).toURI();

Path path = Paths.get( uri );

System.out.printf( "Datei '%s' mit Länge %d Byte(s) hat folgende Zeilen:%n",

path.getFileName(), Files.size( path ) );

int lineCnt = 1;

for ( String line : Files.readAllLines( path /*, StandardCharsets.UTF_8 vor Java 8 */) )

System.out.println( lineCnt++ + ": " + line );
final class java.nio.file.Files
  • static long size(Path path) throws IOException

    Liefert die Größe der Datei.

  • static byte[] readAllBytes(Path path) throws IOException

    Liest die Datei komplett in ein Byte-Feld ein.

  • static List<String> readAllLines(Path path) throws IOException (Java 8)

    static List<String> readAllLines(Path path, Charset cs) throws IOException

    Liest die Datei Zeile für Zeile ein und liefert eine Liste dieser Zeilen. Optional ist die Angabe einer Kodierung, standardmäßig ist es StandardCharsets.UTF_8.

  • static Path write(Path path, byte[] bytes, OpenOption... options) throws IOException

    Schreibt ein Byte-Feld in eine Datei.

  • static Path write(Path path, Iterable<? extends CharSequence> lines,

    OpenOption... options) throws IOException (Java 8)

    static Path write(Path path, Iterable<? extends CharSequence> lines,

    Charset cs, OpenOption... options) throws

    IOException

    Schreibt alle Zeilen aus dem Iterable in eine Datei. Optional ist die Kodierung, die StandardCharsets.UTF_8 ist, sofern nicht anders angegeben.

  • static Stream<String> lines(Path path)

  • Stream<String> lines(Path path, Charset cs)

    Liefert einen Stream von Zeilen einer Datei. Optional ist die Angabe der Kodierung, die sonst standardmäßig StandardCharsets.UTF_8 ist. Beide Methoden sind neu in Java 8.

Die Aufzählung OpenOption ist ein Vararg, und daher sind Argumente nicht zwingend nötig. StandardOpenOption ist eine Aufzählung vom Typ OpenOption mit Konstanten wie APPEND oder CREATE.

[»]Hinweis

Auch wenn es naheliegt, die Files-Methode zum Einlesen mit einem Path-Objekt zu füttern, das einen HTTP-URI repräsentiert, funktioniert dies nicht. So liefert schon die erste Zeile des Programms eine Ausnahme des Typs »java.nio.file.FileSystemNotFoundException: Provider "http" not installed«.

URI uri = new URI( "http://tutego.de/javabuch/aufgaben/bond.txt" ); inline

Path path = Paths.get( uri );

List<String> content = Files.readAllLines( path );

System.out.println( content );

Vielleicht kommt in der Zukunft ein Standard-Provider von Oracle, doch es ist davon auszugehen, dass quelloffene Lösungen diese Lücke schließen werden. Schwer zu programmieren sind Dateisystem-Provider nämlich nicht.

Datenströme kopieren

Sollen die Daten nicht direkt aus einer Datei in ein byte-Feld/eine String-Liste gehen bzw. aus einem byte-Feld/einer String-Sammlung in eine Datei, sondern von einer Datei in einen Datenstrom, so bieten sich zwei copy(…)-Methoden an:

final class java.nio.file.Files
  • static long copy(InputStream in, Path target, CopyOption... options)

    Entleert den Eingabestrom und kopiert die Daten in die Datei.

  • static long copy(Path source, OutputStream out)

    Kopiert alle Daten aus der Datei in den Ausgabestrom.

Im Zusammenhang mit Datenströmen kommen wir noch einmal auf diese beiden Methoden zurück.

 

Zum Seitenanfang

18.2.3Dateien kopieren und verschieben Zur vorigen ÜberschriftZur nächsten Überschrift

Zum Kopieren und Verschieben (bzw. Umbenennen) von Dateien und Verzeichnissen bietet die Files-Klasse eine copy(…)- und eine move(…)-Methode:[ 249 ](Damit ist ein mv bin/laden /dev/null nun auch in Java möglich. )

final class java.nio.file.Files
  • static Path copy(Path source, Path target, CopyOption... options) throws IOException

  • static Path move(Path source, Path target, CopyOption... options) throws IOException

    Kopiert oder verschiebt eine Datei. Die Rückgabe ist der Zielpfad.

Da CopyOption in einem Vararg ist, ist der Aufruf ohne Zusatzoptionen sehr einfach – nur ein Zielort muss angegeben werden:

Listing 18.5com/tutego/insel/nio2/FilesCopyAndMoveDemo.java, main()

Path copySourcePath = Paths.get( "src/lyrics.txt" );

Path copyTargetPath = Paths.get( "src/lyrics – Kopie.txt" );

Files.copy( copySourcePath, copyTargetPath );



Path moveSourcePath = Paths.get( "src/lyrics.txt" );

Path moveTargetPath = Paths.get( "bin/lyrics.txt" );

Files.move( moveSourcePath, moveTargetPath );

Die Methoden versuchen die Dateiattribute auf das Ziel zu übertragen; unterstützt das Ziel ein Attribut nicht, kann es sein, dass nur einige Attribute übertragen werden.

Das Kopieren und Verschieben sind Betriebssystemoperationen, und es ist zu erwarten, dass dies schneller ist, als von Hand die Bytes von einer Stelle zur anderen zu kopieren.

[»]Hinweis

Die Methoden copy(…) und move(…) werden nicht parallel im Hintergrund ausgeführt, sondern blockieren so lange, bis die Operation durchgeführt wurde. Wer es parallel haben möchte, der muss einen Hintergrund-Thread nutzen.

Kopier- und Verschiebeoptionen

copy(…) und move(…) führen zu einer IOException, wenn die Dateien/Verzeichnisse nicht kopiert oder verschoben werden konnten. Das ist insbesondere dann wichtig, wenn sich die Dateiattribute nicht übertragen lassen. Das bringt uns zu den optionalen CopyOption-Elementen. CopyOption ist eine Schnittstelle, die von zwei Aufzählungen StandardCopyOption und LinkOption wie folgt implementiert wird:

Listing 18.6java/nio/file/StandardCopyOption.java, StandardCopyOption

public enum StandardCopyOption implements CopyOption

{

REPLACE_EXISTING,

COPY_ATTRIBUTES,

ATOMIC_MOVE;

}

Listing 18.7java/nio/file/LinkOption.java, LinkOption

public enum LinkOption implements OpenOption, CopyOption

{

NOFOLLOW_LINKS;

}

StandardCopyOption und LinkOption stellen somit gültige Argumente für copy(…) und move(…) dar. Die Bedeutung der Aufzählungselemente ist wie folgt:

Argument

Bedeutung bei copy(…)

Bedeutung bei move(…)

REPLACE_EXISTING

Ersetzt, falls vorhanden, die Datei oder das Verzeichnis am Zielort. Ist das Ziel eine existierende symbolische Verknüpfung, so wird nur die Verknüpfung selbst ersetzt, aber nicht die Datei bzw. das Verzeichnis, auf die/das die Verknüpfung zeigt.

COPY_ATTRIBUTES

Versucht, alle Attribute zu kopieren.

NOFOLLOW_LINKS

Ist der Path eine Verknüpfung, so wird nur die Verknüpfung selbst kopiert, aber nicht die Datei, auf die die Verknüpfung zeigt.

ATOMIC_MOVE

Führt das Verschieben (also das Anlegen der Kopie und das Löschen des Originals) atomar durch. Führt zu AtomicMoveNotSupportedException, falls das Dateisystem dies nicht unterstützt.

Tabelle 18.1Konstanten aus StandardCopyOption

Beim Kopieren von symbolischen Verknüpfungen wird standardmäßig die referenzierte Datei kopiert, aber nicht die Verknüpfung. Daher gibt es die Option NOFOLLOW_LINKS. Falls REPLACE_EXISTING nicht angegeben ist und im Zielordner schon eine Datei bzw. ein Verzeichnis existiert, lösen copy(…) und move(…) eine FileAlreadyExistsException aus. Das Kopieren von Dateien ist nicht automatisch atomar, und eine Option lässt sich auch nicht setzen.

Im Fall von Verzeichnissen wird copy(…) nur ein leeres Verzeichnis anlegen, aber nicht die Dateien eines Quellverzeichnisses automatisch mit kopieren. Das muss per Hand übernommen werden; Files.walkFileTree(…) ist für diesen Fall ganz gut geeignet und hilft beim Ablaufen von Verzeichnisbäumen. Die Semantik bei move(…) und nicht leeren Verzeichnissen ist komplizierter, da es hier darauf ankommt, ob es sich um ein Verschieben auf dem lokalen Dateisystem handelt (also um eine Art »Umbenennen«) oder um ein Verschieben auf zum Beispiel ein anderes Laufwerk. Wenn die Einträge in einem Verzeichnis wirklich auf ein anderes Dateisystem verschoben werden müssen, so übernimmt move(…) diese Arbeit nicht; hier müssen wir selbst per copy(…) auf der Ebene der einzelnen Einträge kopieren.

[»]Hinweis

Kommt es während einer Kopier- oder Verschiebeoperation zu Problemen und tritt eine IO-Exception auf, so müssen wir uns um eventuell übrig gebliebene Reste und halb kopierte Dateien kümmern.

 

Zum Seitenanfang

18.2.4Neue Dateien, Verzeichnisse, symbolische Verknüpfungen anlegen und löschen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Klasse Files deklariert zum Anlegen von neuen Dateien und Verzeichnissen die zwei Methoden createFile(…) und createDirectory(…):

  • static Path createFile(Path path) throws IOException

  • static Path createDirectory(Path dir) throws IOException

Beide Methoden liefern das Path-Objekt zurück, das createFile(…) bzw. createDirectory(…) übergeben wurde. Die Methoden deklarieren throws IOException, wenn die Datei bzw. das Verzeichnis nicht angelegt werden kann, und eine java.nio.file.FileAlreadyExistsException (eine Unterklasse von IOException), wenn die Datei bzw. das Verzeichnis schon existiert.

FileAttribute

Beim Erzeugen neuer Dateien oder Verzeichnisse (auch temporärer) spielen Attribute eine wichtige Rolle. Daher lassen sich den createXXX(…)-Methoden FileAttribute-Argumente übergeben. Sie kommen über ein Vararg, sodass entweder überhaupt keine Attribute mitgegeben werden (das haben wir im oberen Fall so geschrieben) oder eben beliebig viele. Die genaue Deklaration der Methoden lautet:

final class java.nio.file.Files
  • static Path createFile(Path path, FileAttribute<?>... attrs) throws IOException

  • static Path createDirectory(Path dir, FileAttribute<?>... attrs) throws IOException

FileAttribute ist eine Schnittstelle, und bisher gibt es nur eine Stelle in der NIO-API, die Objekte vom Typ FileAttribute liefert: Die Utility-Klasse PosixFilePermissions bietet eine statische Hilfsmethode, die die Menge mit PosixFilePermission-Objekten zurückgibt:

class java.nio.file.attribute.PosixFilePermissions
  • static FileAttribute<Set<PosixFilePermission>> asFileAttribute(

    Set<PosixFilePermission> perms)

    Das Argument für die Methode asFileAttribute(…) ist vom Typ Set<PosixFilePermission>, und diese Menge kann wiederum über EnumSet aufgebaut werden oder über die statische Utility-Methode PosixFilePermissions.fromString(string), die wir schon kennengelernt haben.

Temporäre Dateien und Verzeichnisse anlegen

Vier Methoden der Klasse Files erlauben das Anlegen von temporären Dateien und Verzeichnissen:

final class java.nio.file.Files
  • static Path createTempDirectory(Path dir, String prefix, FileAttribute<?>... attrs)

    throws IOException

  • static Path createTempDirectory(String prefix, FileAttribute<?>... attrs)

    throws IOException

  • static Path createTempFile(Path dir, String prefix, String suffix,

    FileAttribute<?>... attrs) throws IOException

  • static Path createTempFile(String prefix, String suffix, FileAttribute<?>... attrs)

    throws IOException

Misslingt dies, gibt es eine Ausnahme, etwa wenn das Dateisystem keine temporären Dateien zulässt oder die Attribute falsch sind.

Rekursiv alle Verzeichnisse anlegen

Gilt es, ein Verzeichnis rekursiv mit vorangehenden Verzeichnissen anzulegen, übernimmt die statische Methode Files.createDirectories(…) diese Aufgabe:

final class java.nio.file.Files
  • static Path createDirectories(Path dir, FileAttribute<?>... attrs) throws

    IOException

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück

 

 


Copyright © Rheinwerk Verlag GmbH 2017

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de