new FileInputStream(in).getChannel();

[RungetSvohu]

Hallo!

Kann mir einer sagen, was daran so böse ist?

Danke!

 

[Gast2]

Du speicherst dir den FileInputStream in keiner Variablen, damit hast du auch keine Möglichkeit den zu schließen.

 

[RungetSvohu]

Du speicherst dir den FileInputStream in keiner Variablen, damit hast du auch keine Möglichkeit den zu schließen.

Ah, vielen Dank. Derzeit sieht die Funktion nämlich so aus:

	public static void copyFile(File in, File out) throws IOException {
		FileChannel inChannel = new FileInputStream(in).getChannel();
		FileChannel outChannel = new FileOutputStream(out).getChannel();
		inChannel.transferTo(0, inChannel.size(), outChannel);
		inChannel.close();
		outChannel.close();
	}

Hier schließe ich zwar den Channel, aber nicht den Stream. Wenn ich den Stream schließe, wird auch automatisch der Channel geschlossen?

Ist es also so perfekt?

	public static void copyFile(File in, File out) throws IOException {
		FileInputStream fileInputStream = new FileInputStream(in);
		FileOutputStream fileOutputStream = new FileOutputStream(out);
		FileChannel inChannel = fileInputStream.getChannel();
		FileChannel outChannel = fileOutputStream.getChannel();
		inChannel.transferTo(0, inChannel.size(), outChannel);
		fileInputStream.close();
		fileOutputStream.close();
	}

 

[Mujahiddin]

Solche Sachen setzt man grundsätzlich in try-finally Blöcke.
Am besten wäre try-with-resources:

    public static void copyFile(File in, File out) throws IOException {
        try(FileInputStream fileInputStream = new FileInputStream(in);
                FileOutputStream fileOutputStream = new FileOutputStream(out);
                FileChannel inChannel = fileInputStream.getChannel();
                FileChannel outChannel = fileOutputStream.getChannel();) {
            inChannel.transferTo(0, inChannel.size(), outChannel);
        }
    }

Am allerbesten wäre es ja, wenn du stattdessen mit den Java7 Methoden arbeitest:

public static void copyFile(File in, File out) throws IOException {
    Files.copy( in.toPath(), out.toPath() );
}

 

[RungetSvohu]

Und wieso schließt du die Streams in deinem oberen Beispiel nicht.

Stimmt, Java 7 kann ja von Haus aus kopieren. Was ist aber eigentlich mit zusätzlichen MetaInfos zu den Files? Zum Beispiel habe ich meine Methode nun so erweitert:

	public static void copyFile(File in, File out) throws IOException {
		FileInputStream fileInputStream = new FileInputStream(in);
		FileOutputStream fileOutputStream = new FileOutputStream(out);
		FileChannel inChannel = fileInputStream.getChannel();
		FileChannel outChannel = fileOutputStream.getChannel();
		inChannel.transferTo(0, inChannel.size(), outChannel);
		fileInputStream.close();
		fileOutputStream.close();
		out.setLastModified(in.lastModified());
	}

Damit das Änderungsdatum das gleiche bleibt. Macht das Files.copy automatisch?

 

[Mujahiddin]

try-with-resources schließt automatisch, da musst du dich nicht mehr drum kümmern.
FileInputStream sollte (für gewöhnlich) alle abhängigen Streams mitschließen. Ist aber nicht garantiert, deshalb alles einzeln schließen. Am besten mit try-with-resources.

Probier doch aus, ob Files.copy das macht? Änderungsdatum sollte (soweit ich weiß) automatisch überschrieben werden.

 

[docuser]

nur mal so ganz zufällig nebenbei : try-with-resources gibt es auch erst seit java7 ...
der spruch "lieber gleich mit java7 methoden arbeiten" wenn damit explizit NIO.2 File-API gemeint ist ist schon ziemlich witzlos wenn man vorher try-with-resources bringt ...

no comment

 

[Mujahiddin]

@docuser:
try-with-resource gibt es seit Java 7.
NIO-File-API gibt es seit Java 7.
Ich habe OP erklärt, wie er es pre-j7 zu schließen hat (alle nötigen Ressourcen im finally Block closen)
Daraufhin meinte ich, dass, falls er J7 verwendet, try-with-resource angebracht wäre. [warum sollte man überhaupt <j7 verwenden?]
Letztlich meinte ich, dass es für seine Methode bereits vorgefertigte Methoden gibt, nämlich NIO-File-Api, die er statt trywr verwenden kann.

What is the problem? 🙂