Ca fait bien un an que j'ai pas touché de code java, et là je m'y remets, et ça fait drole...
 
J'ai fais ceci pour zipper des fichiers :  
 

 
Je vous passe le code de débug et le choix pourri de nom de variables, ct juste un test quick and dirty...
 
Juste un truc que j'ai oublié, et que j'ai pas réussi à trouver dans l'API java, ni dans le java tutorial :  

je suis pas sur de bien comprendre l'utilisation du buffer ici...c'est une zone tampon que mon input stream remplit, que mon outputstream vide...ce que je comprends pas bien c'est comment ca se gère en interne, parce que le code parait ridiculement simple par rapport à ce qu'il accomplit, à savoir remplir un buffer, le vide, quand il est vide le reremplit, etc...

Je ne comprends pas trop ce qui te gêne dans ce code, mais il y a apparemment plus simple que de gérer ce buffer de bytes :
 
http://www.programmez.com/forum/vi [...] 5d051#1371

L'utilisation d'un buffer est une stratégie classique dans les opérations de lecture/écriture en programmation qui n'est pas obligatoire mais qui a pour but d'améliorer les perfs.

ma question c'est surtout comment java gère la soupe interne de remplir et vider le buffer...c'est ce qui m'a toujours chagriné avec les stream en java, c'est que c'est trop simple : pour bcp d'api, c'est à toi de gérer ce qui se passe, on t'aide juste à la faire...là il se passe plein de choses que je maitrise pas...

Cela dépend du stream que tu utilises.
Un BufferedOutputStream contient un buffer interne pour optimiser les acces entre la couche physique  de ton flux et tes data java.
Maintenant comme c'est un flux, pour limiter le nombre de boucles neccessaires pour la lecture utiliseras à ton tour un buffer pour récupérer le contenu du flux.

tu veux dire que mon code sert à rien, je pourrais aussi bien passer par des bufferedStream et donc pas me taper moi même la gestion du buffer, c'est ça ?

C'est l'idée : si tu as à disposition un stream bufferisé, il est généralement conseillé de l'utiliser.

Une petite précision.
Ton BufferedInputStream contient un buffer interne mais cela ne te dispense pas d'en utiliser un explicite comme dans ton programme pour limiter le nombre de fois que ta boucle de lecture s'effectuera.

?!?!?
 
il me semble que si on utilise un bufferedStream, y'a un constructeur qui permet d'initialiser la taille du buffer, non ?
http://java.sun.com/j2se/1.4.2/doc [...] er,%20int)

T'as un fichier de 1000 cararctères.
Si tu utilise inpustream.read(), tu devras boucler 1000 fois pour lire tout ton fichier.
Indépendement que tu utilises un BufferedInpuStream ou non.
On est d'accord ?
Par contre le inputstream fera un nbre d'acces physique à ton fichier variable selon le fait qu'il soit bufferisé ou pas. Peu d'accès si c'est un BufferInputStream, bcp plus si c'est un FileInputStream simple.
Il y a 2 niveaux de buffer.
 
 

ok...

Ouais mais bon, mis à part le temps d'exécution de la boucle elle-même et le traitement caractère par caractère, supposés négligeables par rapport au temps I/O (si bien fait), pt de vue I/O, ça reste kiff : il n'y aura pas 1000 accès fichier si bufferisé.
 
J'dis pas qu'il faut faire comme ça, mais c'est pas forcément la cata.

Mais bon il y a un minimum de reflexe de bonne pratique à voir tout de même.

question : comment déterminer une bonne taille de buffer ?

adéquation entre la taille de tes fichiers et la mémoire de ta machine/jvm

et y'a des règles pour déterminer la bonne adéquation, ou c du pifomètre à base de "tant que ca plante pas et que c pas trop lent, j'ai bon ?" ?