[Java] I/O, zip, et botanique

I/O, zip, et botanique [Java] - Java - Programmation

Marsh Posté le 26-02-2007 à 13:09:37    

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 :  
 

Code :
  1. buffer = new byte[10000];
  2.  try {
  3.   ZipOutputStream zip = new ZipOutputStream(new FileOutputStream(filename));
  4.   zip.setLevel(Deflater.BEST_COMPRESSION);
  5.   for (int i = 0;i < files.length;i++) {
  6.    FileInputStream file = new FileInputStream(files[i]);
  7.    zip.putNextEntry(new ZipEntry(files[i].getName()));
  8.    int length;
  9.    while ((length = file.read(buffer)) > 0) {
  10.     zip.write(buffer,0,length);
  11.    }
  12.    System.out.println("Fichier ajouté" );
  13.    zip.closeEntry();
  14.    file.close();
  15.   }
  16.   zip.close();


 
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 :  

Code :
  1. while ((length = file.read(buffer)) > 0) {
  2. zip.write(buffer,0,length);
  3. }


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...


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 26-02-2007 à 13:09:37   

Reply

Marsh Posté le 26-02-2007 à 13:52:56    

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

Reply

Marsh Posté le 26-02-2007 à 14:00:57    

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.

Reply

Marsh Posté le 26-02-2007 à 14:19:02    

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...


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 26-02-2007 à 15:20:14    

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.

Reply

Marsh Posté le 26-02-2007 à 19:24:20    

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 ?


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 26-02-2007 à 22:16:45    

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

Reply

Marsh Posté le 27-02-2007 à 15:06:09    

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.

Reply

Marsh Posté le 27-02-2007 à 16:23:22    

?!?!?
 
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)


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 27-02-2007 à 17:25:12    

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.
 
 

Reply

Marsh Posté le 27-02-2007 à 17:25:12   

Reply

Marsh Posté le 27-02-2007 à 19:47:09    

ok... :)


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 28-02-2007 à 08:55:19    

phnatomass a écrit :

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 ?


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. :o


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 28-02-2007 à 11:29:59    

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

Reply

Marsh Posté le 28-02-2007 à 12:38:40    

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 05-03-2007 à 10:15:55    

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


Message édité par cooltwan le 05-03-2007 à 10:16:04
Reply

Marsh Posté le 05-03-2007 à 18:32:15    

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 ?" ?


---------------
Jubi Photos : Flickr - 500px
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed