Discussion :

[Sennad]

Salut à tous !

J'aimerai fusionner des fichiers en java sur une machine Red Hat.
J'ai développé une petite méthode mais rien ne se passe, ça s'exécute, mais rien de plus..
Ma méthode:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public static final void fusionFiles(String firstPath, String destination) {
        try {
            String cmd = "cat " + firstPath + " >> " + destination;
            Process p = Runtime.getRuntime().exec(cmd);
            p.waitFor();
            p.destroy();
        } catch (Exception e) {
            e.printStackTrace();
            System.out.println("Probleme pour fusioner les fichier : " + firstPath + " " + destination);
        }
    }

Aucune exception n'est levée, pas à pas je vois que l'exécution est correcte, ça passe pas dans le catch.
Cette commande marche dans un terminal :
cat /home/test/test >> /home/test/result
Si quelqu'un a une idée ca serrait cool
Merci

[thelvin]

Runtime.exec() n'est pas un terminal.
Il appelle l'API du système d'exploitation qui prend le nom d'un programme et la liste de ses paramètres.

Or >> comme paramètre du programme cat, ça veut dire "fichier nommé >>" et ce fichier n'existe sans doute pas.

Le plus simple serait
- D'utiliser ProcessBuilder
- D'appeler un terminal pour lui donner cette commande à exécuter.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new ProcessBuilder("/bin/sh", "-c", "cat chose >> machin").inheritIO().start().waitFor();

À noter quand même que concaténer avec cat, c'est facile et rapide, ok, mais ça marche que sur les environnements posix, bref pas Windows (ou mobile.) Alors que l'un des atouts de Java est qu'on s'embête pas à se demander sur quel environnement on est, et que concaténer en Java c'est pas non plus si compliqué que ça.

[Sennad]

Salut,

Merci beaucoup pour ta réponse !
C'est super, je me doutais bien que le problème était Runtime.exec(), j'ai eu un autre problème pour md5sum je crois qui était du même ordre, et j'ai dû passer par un processBuilder aussi, mais j'avais pas compris pk, là j'ai compris =D
Merci beaucoup !

Et oui effectivement je pourrai le faire en Java, mais là j'ai besoin de perf, mais surtout mon programme ne tournera jamais sur un Windows ou autre, ça restera sur du red hat.
Donc bon j'en ai pas l'utilité, et c'est quand même plus rapide à dev une petite méthode de 3ptites lignes que dev la méthode complète ^^

Merci encore

[thelvin]

Donc bon j'en ai pas l'utilité, et c'est quand même plus rapide à dev une petite méthode de 3ptites lignes que dev la méthode complète ^^

Jme permets d'avoir des doutes quand même :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public static void fusionFiles(String firstPath, String destination) {
  try(OutputStream out = Files.newOutputStream(Paths.get(destination), APPEND, CREATE)) {
    Files.copy(Paths.get(firstPath), out);
  } catch (Exception e) {
    e.printStackTrace();
    System.out.println("Probleme pour fusioner les fichier : " + firstPath + " " + destination);
  }
}

[adiGuba]

Salut,

Et oui effectivement je pourrai le faire en Java, mais là j'ai besoin de perf, mais surtout mon programme ne tournera jamais sur un Windows ou autre, ça restera sur du red hat.

Heu ? Sérieusement c'est quoi cette excuse en bois ???
En quoi est-ce plus performant de créer un (voir deux) process supplémentaire ?

Donc bon j'en ai pas l'utilité, et c'est quand même plus rapide à dev une petite méthode de 3ptites lignes que dev la méthode complète ^^

Cela prend même pas trois ligne en Java 7 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	public static final void fusionFiles(String firstPath, String destination) throws IOException {
		try (OutputStream out = new FileOutputStream(destination, true)) {
			Files.copy(Paths.get(firstPath), out);
		}
    }

A la rigueur en Java 6 ou inférieur c'est un poil plus long à cause de l'absence de méthode de copie et du try-with-ressource, mais ca prend 2 minutes à écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
	public static final void fusionFiles(String firstPath, String destination) throws IOException {
		InputStream input = new FileInputStream(firstPath);
		try {
			OutputStream output = new FileOutputStream(firstPath, true);
			try {
				byte[] buf = new byte[8192];
				int len;
 
				while ( (len=input.read(buf)) > 0 ) {
					output.write(buf, 0, len);
				}
				output.flush();
 
			} finally {
				output.close();
			}
		} finally {
			input.close();
		}		
    }

[edit] grillé !


a++

[thelvin]

Heu ? Sérieusement c'est quoi cette excuse en bois ???
En quoi est-ce plus performant de créer un (voir deux) process supplémentaire ?

D'un point de vue théorique et si les fichiers sont gros et le programme petit,
- l'overhead de création de process est négligeable
- Java va au moins faire, ce que cat ne fait pas, passer son temps à vérifier que les indexes du buffer sont valides

... Mais en pratique j'y crois pas des masses quand même.

[Sennad]

Je ne pense pas (je peux me tromper) que ca soit plus rapide.
Puis j'en ai absolument aucun interet, mais alors aucun, alors pk faire ?
Mais c'est bon à savoir.
Merci encore

[Sennad]

Apres quelque test :
Avec cat c'est 3.7 fois plus long qu'avec Files.copy
J’ai bouclé 5000 fois en appelant la méthode.
34 secondes vs 9 secondes ^^
Merci adiGuba ^^
Bon ça me sert quand même à rien xD mais ça coute rien de laisser comme ça

[adiGuba]

... Mais en pratique j'y crois pas des masses quand même.

Franchement je doute vraiment que l'appel d'un cat via un shell soit plus rapide.

Si on doit traiter de gros fichier, le plus rapide serait alors de passer par des FileChannel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
		try (FileChannel input = FileChannel.open(Paths.get(firstPath));
			FileChannel output = FileChannel.open(Paths.get(destination), StandardOpenOption.CREATE, StandardOpenOption.APPEND)) {
			input.transferTo(0, input.size(), output);
		}

a++

[adiGuba]

Apres quelque test :
Avec cat c'est 3.7 fois plus long qu'avec Files.copy
J’ai bouclé 5000 fois en appelant la méthode.
34 secondes vs 9 secondes ^^

Logique : cat doit faire sensiblement la même chose que Files.copy() !
Donc le faire immédiatement doit être plus rapide que d'exécuter un shell (/bin/sh) pour lui demander d'appeler un programme (cat) pour au final faire la même chose...



[edit] Et en plus on aura une meilleure remontée d'erreur !

a++

[Sennad]

Yep ! C'est super merci encore