Comment tester si un flush a bien été fait ?

Version imprimable

19/07/2008, 15h32
gifffftane

Comment tester si un flush a bien été fait ?

Bonjour,

Honte à moi, j'oublie très régulièrement de faire le flush de mes flux de sortie, par exemple le BufferedWriter, ce qui provoque des bugs souvent difficiles à découvrir.

Le plus ennuyeux est que je ne vois absolument pas comment on peut tester si, à sa fermeture, un flux a bien été flushé auparavant ?
19/07/2008, 19h54
wiztricks

Bonsoir,
pourquoi ne pas "flusher" sans se poser de question?
-W

Il n'y a pas de moyen de savoir s'il y a eu un flush ou non. La solution est de faire un flush() avant de faire le close(). Je trouve que ça rejoint un peu les problèmes de gestion des sessions/transactions que l'on avait avant où on avait oublié de faire un close.

Une solution serait de gérer ça via un modèle de conception Template ou alors via des aspects.

Pour le template où on pourrait imaginer quelque chose comme ça (je ne sais pas si c'est vraiment utilisable, à creuser) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 abstract class Template { public void execute(BufferedWriter writter) { try { handle(writter); } catch(IOException e) { // ... } finally { try { if(writter != null) { writter.flush(); writter.close(); } } catch(IOException e) { // ... } } } protected abstract void handle(BufferedWriter writter) throws IOException; }

20/07/2008, 13h50
gifffftane

Citation:

Envoyé par wiztricks

Bonsoir,
pourquoi ne pas "flusher" sans se poser de question?
-W

Ben précisement parce que je l'oublie ! Donc... je suis bien obligé de me poser des questions. Cela fait presque 1 mois que je cherche un bug indémerdable à cause d'un flush oublié dans un coin oublié, donc je cherche à ne pas recommencer !

Citation:

Envoyé par darkxan

Une solution serait de gérer ça via un modèle de conception Template ou alors via des aspects.

Je m'étais fait le même genre de réflexion : impossible de tester l'usage du flush. (d'où ma question ici)

Tu présentes un exemple de Template ; cela à l'air d'être de méthode toute prête ; mais, par Template, est-ce que tu fais référence à un méthodologie particulière, ou est-ce que c'est simplement l'idée de regrouper flush/close dans un utilitaire ?

J'avais pensé aux aspects aussi, mais je ne m'y connais pas beaucoup dans ce domaine ; je m'étais simplement dit que d'après ce que j'avais compris des aspects, un truc qui s'applique à un ensemble d'objets variés, cela pouvait peut être être une piste. As-tu un exemple dans ce domaine ?

Comme je l'ai précisé dans mon message précédent Template [GOF] est un modèle de conception ou design pattern.

Il est pour implémenter des parties invariantes d'un algorithme et laisser les sous classes s'occuper du comportement.
Cela permet aussi d'éviter de la duplication de code et rentre plus généralement dans le refactoring de code.
Si tu veux en savoir plus, je te conseille la littérature sur ce design pattern.

J'ai fait un rapprochement avec les transactions et ce n'est pas innocent car avant l'avènement des aspects, il était très pratique d'utiliser des templates pour gérer les transactions. Cela évitait les problèmes de copier/coller et d'oubli comme tu l'as actuellement avec ta méthode flush().

Je ne sais exactement ce que tu as lu les aspects mais il faut vraiment le voir comme la capacité d'ajouter des fonctionnalités à des méthodes. Les exemples classiques sont la gestion des logs, la gestion des exceptions, la sécurité, les transactions, etc...
Fondamentalement, c'est trop proche de la classe Template que j'ai présenté au dessus en parlant d'éviter la duplication de code.
Si je prends l'exemple des transactions avec une méthode createUser, si je gère manuellement mon aspect je devrais créer une méthode autour de la méthode de création.

Par exemple on pourrait gérer les transactions de cette manière (attention c'est juste un schéma pour donner une idée) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public void createUser(User user) { this.userDAO.save(user); } public void transactionAspect(JoinPoint p, Object... args) { try { Session session = sessionFactory.getCurrentSession(); Transaction tx = session.beginTransaction(); p.execute(args); tx.commit(); } catch(RuntimeException e) { if(tx != null) { tx.rollback(); } } }
On voit bien que cela correspond fortement à l'idée de template au dessus sauf que c'est bien plus puissant car on choisir d'exécuter ce bout de code avant l'appel à la méthode, après son appel, après une exception ou au tour comme dans le code précédent.

Donc en conclusion, effectivement tu pourrais utiliser des aspects pour gérer ton problème mais cela à tout de même des contraintes : il faut pouvoir accéder facilement à ta ressource le BufferedWritter. Dans le cas des transactions, c'est le pied car on peut accéder très facilement à la session et donc aux transactions; ici cela me semble plus dur d'accéder facilement à ton Writter.

Une solution serait donc que la méthode prennent en paramètre Writter comme ça l'aspect pourrait le récupérer sans problème soit il faudrait créer un système similaire au session dans le cas de la gestion des BD qui te permettrait de savoir avec quel Writter tu travailles actuellement. La deuxième solution demande d'avoir une architecture assez particulière alors que le premier cas peut s'appliquer partout.

Donc on voit bien que les deux solutions Template ou aspects ne répondent pas forcément parfaitement aux besoins de gestion des ressources et c'est cela qui doit expliquer pourquoi on ne voit peu de code utiliser ces méthodes dans ce cas.

20/07/2008, 14h44
wiztricks

Citation:

Ben précisement parce que je l'oublie ! Donc... je suis bien obligé de me poser des questions. Cela fait presque 1 mois que je cherche un bug indémerdable à cause d'un flush oublié dans un coin oublié, donc je cherche à ne pas recommencer !

Pourquoi ne pas dériver "BufferedWriter" et surcharger le close avec un code qui fasse ce "flush"?
- W
20/07/2008, 15h28
gifffftane

Citation:

Envoyé par darkxan

Comme je l'ai précisé dans mon message précédent Template [GOF] est un modèle de conception ou design pattern.

C'est le Patron de méthode (ou Template method ) ?

Citation:

Envoyé par darkxan

Donc en conclusion, effectivement tu pourrais utiliser des aspects pour gérer ton problème mais cela à tout de même des contraintes : il faut pouvoir accéder facilement à ta ressource le BufferedWritter. Dans le cas des transactions, c'est le pied car on peut accéder très facilement à la session et donc aux transactions; ici cela me semble plus dur d'accéder facilement à ton Writter.

Cela ne me dérange qu'à moitié de rendre mon BufferedWritter public, car j'ai l'habitude de rendre publics les objets sensibles pour les tests. Je préfère avoir un objet public et fiable, plutôt qu'un objet privé où c'est le bordel :mouarf:

Je vais essayer d'approfondir ces aspects, dans lesquels je suis trop novice pour me faire une opinion. L'occasion est bonne, d'autant plus que j'aborde aussi Spring en ce moment, et que, en plus, à ce que je comprends, l'usage du pattern Template est un bon début.

À terme, j'ai l'espoir, me semble-t-il, que Template+Aspect puisse rendre mon flush testable, puisque j'aurai factorisé mon code, et que donc mon problème qui est disséminé partout sera rassemblé en un seul point bien identifié. (la procédure classique pour fiabiliser son code, quoi).

Citation:

Envoyé par wiztricks

Pourquoi ne pas dériver "BufferedWriter" et surcharger le close avec un code qui fasse ce "flush"?
- W

À partir du moment où l'on dit C'est pas testable, ton idée est effectivement bonne. Il me semble qu'on peut la voir comme une forme du pattern Template, non ?

Merci à tous deux pour vos réflexions.
20/07/2008, 16h02
darkxan
Citation:

C'est le Patron de méthode (ou Template method ) ?

Euh... C'est la même chose sauf que l'un est en français l'autre en anglais.

Citation:

car j'ai l'habitude de rendre publics les objets sensibles pour les tests

Pour ma part, je ne modifie jamais mon code pour effectuer des tests. Si je dois tester un champs privé ou une méthode privée, j'utilise l'api reflection qui permet de faire ça très aisément.

J'ai des méthodes toutes faites comme : Object invoke(Object objet, String methodName, Object... args)

Citation:

À partir du moment où l'on dit C'est pas testable, ton idée est effectivement bonne. Il me semble qu'on peut la voir comme une forme du pattern Template, non ?

Je ne pense pas, ici c'est juste un héritage tout bête. Je te laisse regarder en détail le pattern Template. Par contre, tu pourrais faire en sorte que pour tes tests, tu utilises ta version spécialisée de ton BufferedReader qui fait un test si oui ou non le buffer a été flushée, comment ?
Simplement en faisant en override de toutes les méthodes d'écritures et en ajoutant un boolean flushed.
Code:

1 2 3 4 BufferedReader getBufferedReader(Reader reader) { // return new BufferedReader(reader); return new TestBufferedReader(reader); }
20/07/2008, 16h31
wiztricks

Stricto sensu, le pattern template permet de factoriser l'implémentation de certaines méthodes pour en laisser certains détails à des classes dérivées.

Dans notre cas, nous n'avons pas grand chose à factoriser sinon "adapter" un peu l'objet BufferedWriter pour qu'il n'oublie pas de faire un flush avant le close.

- W
20/07/2008, 18h24
gifffftane

À partir de quel moment un héritage tout bête devient un pattern Template... :koi: Avec un jeu de méthodes final et abstract, mais aucun des deux ne semble vraiment obligatoire, d'après l'article de wikipedia. :chin:

Bon, merci à tous, grâce à vous je vais me remettre au travail sur ces questions !
20/07/2008, 21h04
darkxan

Je cite (Template Method [GOF]) :
"A template method defines an alogorithm in terms of abstract operations that subclass override to provide concrete behavior."

Mon exemple de Template correponds exactement à ça. L'algorithme est execute, il définit un ensemble d'étapes et une opération abstraite qui est handle. Celle-ci va être surchargée par les classes filles.

Dans ton cas, tu n'as pas de classe Template. Tu as un BufferedWriter qui définit une méthode close mais qui ne définit aucun algorithme et aucune opérations abstraites. Tu as simplement surchargée cette méthode pour lui ajouter un comportement. Et il n'y a dans ton exemple qu'une seule classe fille ce qui n'est pas non plus la philosophie du Template.

En effet, on peut aussi le rapprocher du modèle de conception : Stratégie. C'est en cela que l'on voit qu'il y a plusieurs classes filles qui ont chacune un comportement différent pour chaque méthode abstraite.

Si tu utilisais mon example de Template, tu serais obligé de définir autant de classe que tu as de traitements sur tes BufferedWriter.
20/07/2008, 22h08
wiztricks

dériver et surcharger correspond mieux au pattern adapter.
- W
20/07/2008, 23h48
gifffftane

Oui, ok, sauf que la classe BufferedWriter descend de la classe Writer, qui est abstract, qui stipule diverses méthodes abstraites et concrètes, dans l'objectif de définir un modèle d'écriture de flux de caractères. Alors Writer est un Template selon la définition du GOF. Donc BufferedWriter est aussi un Template, puisque il hérite de Writer. Le fait qu'il soit une concrétisation ne l'empêche pas de conserver les propriétés du modèle, et de pouvoir servir de modèle à son tour.

Certes, ton exemple correspond très bien à la définition également, et je t'en remercie. Il me permet de réfléchir pour trouver si ma problématique est vraiment différente de celle du BufferedWriter, auquel cas j'ai meilleur compte à créer un Template séparé comme tu le proposes, ou si c'est pareil à peu de choses près, auquel cas je sous-classe BufferedWriter. Il y a aussi la piste des interfaces Flushable et Closeable qui pourraient me servir de base.

Je crois qu'il faut laisser ouvertes toutes ces définitions et tous ces principes, tout en conservant et comprenant leurs formes originales, pour voir comment ils découvrent différents cas.
20/07/2008, 23h58
wiztricks

Hu?!? Je préfére mettre une certaine distance entre les patterns de conception et les implémentations. Sinon nous allons dire qu'un template C++ colle au pattern template.
- W
21/07/2008, 09h04
OButterlin
Citation:

Envoyé par darkxan

Il n'y a pas de moyen de savoir s'il y a eu un flush ou non. La solution est de faire un flush() avant de faire le close().

A moins d'avoir raté un concept, je ne vois pas l'intérêt de faire un flush() suivit d'un close() puisque la méthode close() fait un flush() avant comme indiqué dans la doc
http://java.sun.com/javase/6/docs/ap...redWriter.html
Code:

1 2 3 void close() Closes the stream, flushing it first.
Y aurait-il une raison particulière ou s'agit-il d'un problème lié à autre chose qu'un BufferedWriter ?
21/07/2008, 09h09
darkxan

LOL. Je me disais depuis hier que c'était étrange qu'il ne faisait pas un flush avant de faire un close. Je me suis fait avoir car dans la doc 1.4 sur le BufferedWriter il ne le mentionne pas.
21/07/2008, 09h43
OButterlin

Citation:

Envoyé par darkxan

LOL. Je me disais depuis hier que c'était étrange qu'il ne faisait pas un flush avant de faire un close. Je me suis fait avoir car dans la doc 1.4 sur le BufferedWriter il ne le mentionne pas.

Disons que le lien n'est pas direct, mais si tu cliques sur close dans

Citation:

Specified by:close in class Writer

ils le disent également ;)

Ce n'est pas aussi clair que ce que dit la doc, malheureusement. Moi aussi j'avais été surpris, surtout en constatant que mes closes avaient toutes les caractéristiques d'un flush mal fait.

Voici les sources 1.6 des flush et close du BufferedWriter :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public void flush() throws IOException { synchronized (lock) { flushBuffer(); out.flush(); } } public void close() throws IOException { synchronized (lock) { if (out == null) { return; } try { flushBuffer(); } finally { out.close(); out = null; cb = null; } } }
On voit donc que le close fait une sorte de flush incomplet par rapport à la méthode flush (seulement flushBuffer, sans out.flush). Je ne peux pas l'affirmer mordicus, n'ayant pas tout compris du code du BufferedWriter, mais...

Coté BufferedOutputStream, à voir le code, les choses sont plus claires : close appelle bien la méthode flush elle même, donc le close fait bien un flush complet chez les streams.

Qu'en pensez-vous ?

21/07/2008, 12h48
wiztricks

Citation:

On voit donc que le close fait une sorte de flush incomplet par rapport à la méthode flush (seulement flushBuffer, sans out.flush). Je ne peux pas l'affirmer mordicus, n'ayant pas tout compris du code du BufferedWriter, mais...

Est-ce que out.close n'appelle pas out.flush?

La cause de la cause?
Si cela n'est pas la cause du problème qui vous a posé tracas, ajouter des "flush" contournerait un problème dont la cause n'a pas été identifiée...
Ce qui est quand même pus génant (pour votre application).
- W
21/07/2008, 13h40
gifffftane
Dans mon cas le BufferedWriter contenait un FileWriter ; pour le FileWriter, c'est le OutputStreamWriter qui s'occupe des flush et close. Voici le code :
Code:

1 2 3 4 5 6 7 public void flush() throws IOException { se.flush(); } public void close() throws IOException { se.close(); }
Donc, pas d'appel du flush dans le close à ce niveau là. Quand à se, c'est un sun.nio.cs.StreamEncoder, dont les sources ne sont pas dispo ; je ne peux pas remonter plus loin.

Il est vrai que l'origine du problème peut être discutée, tant qu'il n'a pas été prouvé que close n'appelle pas systématiquement le flush. En tous les cas je n'ai pas vu du bug enregistré là dessus.

Mumpf. Pas facile. Peut être que je coupe des cheveux en 4 dans la mauvaise direction.

Le code de la classe

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
 
/*
    2    * Copyright 2001-2005 Sun Microsystems, Inc.  All Rights Reserved.
    3    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
    4    *
    5    * This code is free software; you can redistribute it and/or modify it
    6    * under the terms of the GNU General Public License version 2 only, as
    7    * published by the Free Software Foundation.  Sun designates this
    8    * particular file as subject to the "Classpath" exception as provided
    9    * by Sun in the LICENSE file that accompanied this code.
   10    *
   11    * This code is distributed in the hope that it will be useful, but WITHOUT
   12    * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
   13    * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
   14    * version 2 for more details (a copy is included in the LICENSE file that
   15    * accompanied this code).
   16    *
   17    * You should have received a copy of the GNU General Public License version
   18    * 2 along with this work; if not, write to the Free Software Foundation,
   19    * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
   20    *
   21    * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
   22    * CA 95054 USA or visit www.sun.com if you need additional information or
   23    * have any questions.
   24    */
   25   
   26   /*
   27    */
   28   
   29   package <a href="http://www.docjar.com/docs/api/sun/nio/cs/package-index.html" target="_blank">sun.nio.cs</a>;
   30   
   31   import <a href="http://www.docjar.com/docs/api/java/io/package-index.html" target="_blank">java.io</a>;
   32   import <a href="http://www.docjar.com/docs/api/java/nio/package-index.html" target="_blank">java.nio</a>;
   33   import <a href="http://www.docjar.com/docs/api/java/nio/channels/package-index.html" target="_blank">java.nio.channels</a>;
   34   import <a href="http://www.docjar.com/docs/api/java/nio/charset/package-index.html" target="_blank">java.nio.charset</a>;
   35   
   36   public class StreamEncoder extends Writer
   37   {
   38   
   39       private static final int DEFAULT_BYTE_BUFFER_SIZE = 8192;
   40   
   41       private volatile boolean isOpen = true;
   42   
   43       private void ensureOpen() throws IOException {
   44           if (!isOpen)
   45               throw new IOException("Stream closed");
   46       }
   47   
   48       // Factories for java.io.OutputStreamWriter
   49       public static StreamEncoder forOutputStreamWriter(OutputStream out,
   50                                                         Object lock,
   51                                                         String charsetName)
   52           throws UnsupportedEncodingException
   53       {
   54           String csn = charsetName;
   55           if (csn == null)
   56               csn = Charset.defaultCharset().name();
   57           try {
   58               if (Charset.isSupported(csn))
   59                   return new StreamEncoder(out, lock, Charset.forName(csn));
   60           } catch (IllegalCharsetNameException x) { }
   61           throw new UnsupportedEncodingException (csn);
   62       }
   63   
   64       public static StreamEncoder forOutputStreamWriter(OutputStream out,
   65                                                         Object lock,
   66                                                         Charset cs)
   67       {
   68           return new StreamEncoder(out, lock, cs);
   69       }
   70   
   71       public static StreamEncoder forOutputStreamWriter(OutputStream out,
   72                                                         Object lock,
   73                                                         CharsetEncoder enc)
   74       {
   75           return new StreamEncoder(out, lock, enc);
   76       }
   77   
   78   
   79       // Factory for java.nio.channels.Channels.newWriter
   80   
   81       public static StreamEncoder forEncoder(WritableByteChannel ch,
   82                                              CharsetEncoder enc,
   83                                              int minBufferCap)
   84       {
   85           return new StreamEncoder(ch, enc, minBufferCap);
   86       }
   87   
   88   
   89       // -- Public methods corresponding to those in OutputStreamWriter --
   90   
   91       // All synchronization and state/argument checking is done in these public
   92       // methods; the concrete stream-encoder subclasses defined below need not
   93       // do any such checking.
   94   
   95       public String getEncoding() {
   96           if (isOpen())
   97               return encodingName();
   98           return null;
   99       }
  100   
  101       public void flushBuffer() throws IOException {
  102           synchronized (lock) {
  103               if (isOpen())
  104                   implFlushBuffer();
  105               else
  106                   throw new IOException("Stream closed");
  107           }
  108       }
  109   
  110       public void write(int c) throws IOException {
  111           char cbuf[] = new char[1];
  112           cbuf[0] = (char) c;
  113           write(cbuf, 0, 1);
  114       }
  115   
  116       public void write(char cbuf[], int off, int len) throws IOException {
  117           synchronized (lock) {
  118               ensureOpen();
  119               if ((off < 0) || (off > cbuf.length) || (len < 0) ||
  120                   ((off + len) > cbuf.length) || ((off + len) < 0)) {
  121                   throw new IndexOutOfBoundsException();
  122               } else if (len == 0) {
  123                   return;
  124               }
  125               implWrite(cbuf, off, len);
  126           }
  127       }
  128   
  129       public void write(String str, int off, int len) throws IOException {
  130           /* Check the len before creating a char buffer */
  131           if (len < 0)
  132               throw new IndexOutOfBoundsException();
  133           char cbuf[] = new char[len];
  134           str.getChars(off, off + len, cbuf, 0);
  135           write(cbuf, 0, len);
  136       }
  137   
  138       public void flush() throws IOException {
  139           synchronized (lock) {
  140               ensureOpen();
  141               implFlush();
  142           }
  143       }
  144   
  145       public void close() throws IOException {
  146           synchronized (lock) {
  147               if (!isOpen)
  148                   return;
  149               implClose();
  150               isOpen = false;
  151           }
  152       }
  153   
  154       private boolean isOpen() {
  155           return isOpen;
  156       }
  157   
  158   
  159       // -- Charset-based stream encoder impl --
  160   
  161       private Charset cs;
  162       private CharsetEncoder encoder;
  163       private ByteBuffer bb;
  164   
  165       // Exactly one of these is non-null
  166       private final OutputStream out;
  167       private WritableByteChannel ch;
  168   
  169       // Leftover first char in a surrogate pair
  170       private boolean haveLeftoverChar = false;
  171       private char leftoverChar;
  172       private CharBuffer lcb = null;
  173   
  174       private StreamEncoder(OutputStream out, Object lock, Charset cs) {
  175           this(out, lock,
  176            cs.newEncoder()
  177            .onMalformedInput(CodingErrorAction.REPLACE)
  178            .onUnmappableCharacter(CodingErrorAction.REPLACE));
  179       }
  180   
  181       private StreamEncoder(OutputStream out, Object lock, CharsetEncoder enc) {
  182           super(lock);
  183           this.out = out;
  184           this.ch = null;
  185           this.cs = enc.charset();
  186           this.encoder = enc;
  187   
  188           // This path disabled until direct buffers are faster
  189           if (false && out instanceof FileOutputStream) {
  190                   ch = ((FileOutputStream)out).getChannel();
  191           if (ch != null)
  192                       bb = ByteBuffer.allocateDirect(DEFAULT_BYTE_BUFFER_SIZE);
  193           }
  194               if (ch == null) {
  195           bb = ByteBuffer.allocate(DEFAULT_BYTE_BUFFER_SIZE);
  196           }
  197       }
  198   
  199       private StreamEncoder(WritableByteChannel ch, CharsetEncoder enc, int mbc) {
  200           this.out = null;
  201           this.ch = ch;
  202           this.cs = enc.charset();
  203           this.encoder = enc;
  204           this.bb = ByteBuffer.allocate(mbc < 0
  205                                     ? DEFAULT_BYTE_BUFFER_SIZE
  206                                     : mbc);
  207       }
  208   
  209       private void writeBytes() throws IOException {
  210           bb.flip();
  211           int lim = bb.limit();
  212           int pos = bb.position();
  213           assert (pos <= lim);
  214           int rem = (pos <= lim ? lim - pos : 0);
  215   
  216               if (rem > 0) {
  217           if (ch != null) {
  218               if (ch.write(bb) != rem)
  219                   assert false : rem;
  220           } else {
  221               out.write(bb.array(), bb.arrayOffset() + pos, rem);
  222           }
  223           }
  224           bb.clear();
  225           }
  226   
  227       private void flushLeftoverChar(CharBuffer cb, boolean endOfInput)
  228           throws IOException
  229       {
  230           if (!haveLeftoverChar && !endOfInput)
  231               return;
  232           if (lcb == null)
  233               lcb = CharBuffer.allocate(2);
  234           else
  235               lcb.clear();
  236           if (haveLeftoverChar)
  237               lcb.put(leftoverChar);
  238           if ((cb != null) && cb.hasRemaining())
  239               lcb.put(cb.get());
  240           lcb.flip();
  241           while (lcb.hasRemaining() || endOfInput) {
  242               CoderResult cr = encoder.encode(lcb, bb, endOfInput);
  243               if (cr.isUnderflow()) {
  244                   if (lcb.hasRemaining()) {
  245                       leftoverChar = lcb.get();
  246                       if (cb != null && cb.hasRemaining())
  247                           flushLeftoverChar(cb, endOfInput);
  248                       return;
  249                   }
  250                   break;
  251               }
  252               if (cr.isOverflow()) {
  253                   assert bb.position() > 0;
  254                   writeBytes();
  255                   continue;
  256               }
  257               cr.throwException();
  258           }
  259           haveLeftoverChar = false;
  260       }
  261   
  262       void implWrite(char cbuf[], int off, int len)
  263           throws IOException
  264       {
  265           CharBuffer cb = CharBuffer.wrap(cbuf, off, len);
  266   
  267           if (haveLeftoverChar)
  268           flushLeftoverChar(cb, false);
  269   
  270           while (cb.hasRemaining()) {
  271           CoderResult cr = encoder.encode(cb, bb, false);
  272           if (cr.isUnderflow()) {
  273              assert (cb.remaining() <= 1) : cb.remaining();
  274              if (cb.remaining() == 1) {
  275                   haveLeftoverChar = true;
  276                   leftoverChar = cb.get();
  277               }
  278               break;
  279           }
  280           if (cr.isOverflow()) {
  281               assert bb.position() > 0;
  282               writeBytes();
  283               continue;
  284           }
  285           cr.throwException();
  286           }
  287       }
  288   
  289       void implFlushBuffer() throws IOException {
  290           if (bb.position() > 0)
  291           writeBytes();
  292       }
  293   
  294       void implFlush() throws IOException {
  295           implFlushBuffer();
  296           if (out != null)
  297           out.flush();
  298       }
  299   
  300       void implClose() throws IOException {
  301           flushLeftoverChar(null, true);
  302           try {
  303               for (;;) {
  304                   CoderResult cr = encoder.flush(bb);
  305                   if (cr.isUnderflow())
  306                       break;
  307                   if (cr.isOverflow()) {
  308                       assert bb.position() > 0;
  309                       writeBytes();
  310                       continue;
  311                   }
  312                   cr.throwException();
  313               }
  314   
  315               if (bb.position() > 0)
  316                   writeBytes();
  317               if (ch != null)
  318                   ch.close();
  319               else
  320                   out.close();
  321           } catch (IOException x) {
  322               encoder.reset();
  323               throw x;
  324           }
  325       }
  326   
  327       String encodingName() {
  328           return ((cs instanceof HistoricallyNamedCharset)
  329               ? ((HistoricallyNamedCharset)cs).historicalName()
  330               : cs.name());
  331       }
  332   }

En isolant l'essentiel, il semble que le contrat close() écrit tous les caractères non enregistrés soit OK.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
void implClose() throws IOException {
   flushLeftoverChar(null, true);
   try {
       for (;;) {
           CoderResult cr = encoder.flush(bb);
           if (cr.isUnderflow())
               break;
           if (cr.isOverflow()) {
               assert bb.position() > 0;
               writeBytes();
               continue;
           }
           cr.throwException();
       }
 
       if (bb.position() > 0)
           writeBytes();
       if (ch != null)
           ch.close();
       else
           out.close();
   } catch (IOException x) {
       encoder.reset();
       throw x;
   }
}
 
void implFlushBuffer() throws IOException {
   if (bb.position() > 0)
   writeBytes();
}
 
void implFlush() throws IOException {
   implFlushBuffer();
   if (out != null)
   out.flush();
}

21/07/2008, 15h40
gifffftane

Je vais voir si je peux tester ça, cela ne me parait toujours pas net que le implClose face le flush du flux englobé. Et toi, cela te parait clair ? Le implFlush, lui fait bien out.flush(), mais je ne vois rien de similaire quand au close.

Bon je vais faire une démo de preuve.
21/07/2008, 15h48
OButterlin

Il est certain que ce n'est pas le même code, mais elles font bien appel toutes les 2 à writeBytes() pour écrire les données dans le flux de sortie (ici un OutputStream)
Donc, dans le principe, le close fait bien un "flush" avant de fermer le flux (même s'il le fait d'une autre façon)

Ah, je comprends, tu veux dire qu'il fait une sorte de flush, mais sans appeler la méthode flush, seulement par un writeBytes... Mais si le flux est buffurisé, tu peux toujours faire autant de out.writeBytes, il ne sera toujours pas flushé, ou alors j'ai mal compris le principe ? (ce qui m'arrive souvent).

En tous les cas, j'ai fait un essai, et il me parait maintenant clair que le close ne déclenche pas le flush officiel du flux englobé. Le code de preuve pour ceux que ça intéresse :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 package zou; import java.io.BufferedWriter; import java.io.File; import java.io.IOException; public class FlushedOrNotFlushed { public static class IsFlushedFileWriter extends java.io.FileWriter { IsFlushedFileWriter(File toto) throws IOException { super(toto); } @Override public void flush() throws IOException { System.out.println("C'est BON !"); super.flush(); } } public static void main(String[] args) throws Exception { BufferedWriter buf = new BufferedWriter(new IsFlushedFileWriter(new File("toto.txt"))); buf.write("Hello mister"); buf.close(); System.out.print("Voyez-vous le C'est BON ?"); } }
Et je n'ai pas de C'est BON...

21/07/2008, 16h20
OButterlin

Oui, c'est normal...
Mais comme dit, il ne passe pas par la méthode flush() mais il fait l'équivalent (ce qui, me semble-t-il, est l'essentiel ;))
21/07/2008, 19h44
wiztricks

Dit autrement, ca ne passe pas par flush mais il faut regarder si les "caractères" bufférisés ont bien été écrits.
- W
21/07/2008, 20h09
gifffftane

Oui enfin moi je trouve ça un peu cavalier : quand la doc dit que le flux est flushé, je m'attends à ce que cela passe par la méthode flush, et non par quelque obscure fonctionnalité d'implémentation du paquetage com.sun.truc.machin...

Bon, je rouspète, je rouspète, je rouspète, mais avec tout ça j'ai toujours pas trouvé mon bug : je vois bien qu'il arrive que le fichier ne soit pas bien écrit.

Bon, je vais continuer à chercher, merci pour tout.
21/07/2008, 20h15
wiztricks
Citation:

Bon, je rouspète, je rouspète, je rouspète, mais avec tout ça j'ai toujours pas trouvé mon bug : je vois bien qu'il arrive que le fichier ne soit pas bien écrit.

Est-ce que:
- le problème se reproduit avec une fréquence intéressante?
- on sait le détecter rapidement?
- forcer un flush avant le close "résoud" le problème?
- W
21/07/2008, 20h22
gifffftane

Oui à tout ça, sauf que ça se produit sur un PC à 300 km de chez moi auquel je n'ai pas accès ! (et sur le mien tout se passe bien évidemment).

Au fond, peut être l'utilisateur éteint-il sa machine au beau milieu de l'exécution du programme ??
21/07/2008, 20h46
wiztricks

Forcer le flush avant le close à au moins le mérite de masquer le problème.
Pour en comprendre la cause, il va falloir compter sur de la chance ;)
Mais il n'est peut être pas utile de s'acharner non plus.
Bon courage
- W
22/07/2008, 08h35
OButterlin

Citation:

Envoyé par gifffftane

Au fond, peut être l'utilisateur éteint-il sa machine au beau milieu de l'exécution du programme ??

C'est clair que s'il sort de son programme de manière brutale, faut pas compter sur la jvm pour forcer le flush :mouarf:
Je pense que tu tiens là une bonne piste...
(Perso, je n'ai jamais vu un flux partiellement tronqué quand on n'oublie pas le close()...)

Bonne chance
A+
22/07/2008, 12h54
darkxan

Peut être alors ajouter un shutdown hook si tu penses que le problème vient de la fermeture abrupte du programme.

http://java.sun.com/j2se/1.5.0/docs/...a.lang.Thread)
22/07/2008, 17h40
gifffftane

Non, ça au moins, c'est impossible : un utilisateur comme tout le monde est totalement incapable d'arrêter brutalement un programme, à part en coupant le courant.

Enfin bon de toutes façons le problème semble résolu, grâce à quelques rustines par-ci par-là. Ma grande déception est qu'il soit difficile de vérifier le flush, à cause des finasseries JVM.
:applo: