Re: BufferedOutputStream patch

[Warren Levy <warrenl@cygnus.com>]

John-Marc,
First off, please note I've also cc'ed this to the mauve-discuss list
(in addition to the java-discuss list you originally addressed) as there 
are folks following mauve-discuss who have valuable input on Java lib 
issues like this.

Notwithstanding the VM behavior you observed, the doc I checked is not
consistently clear on what should be done.  The Java Class Libraries 
book (Second Edition, ISBN 0-201-31002-3) agrees with you for 
BufferedOutputStream in JDK 1.1, "If there is room in the buffer 
of this stream to hold the bytes, they are buffered..."

But for BufferedWriter it says "If this writer's internal buffer becomes 
full as a result of this write, the contents of the internal buffer are 
flushed..." which is what the libgcj code seems to be doing when I look 
at it (though unless I misunderstood your original msg, you claim that 
BufferedWriter.write in libgcj behaves otherwise and doesn't do the flush 
until the buffer overflows).

Though BufferedOutputStream needs a fix to one of it's 2 write methods to 
make them behave consistent with each other in this respect, I am holding 
off applying your patch temporarily because of what I found when looking 
at the JDK 1.2 doc.

Though the JDK 1.2 online doc doesn't say anything specific on this 
issue for BufferedWriter, it does contradict the JCL book on 
BufferedOutputStream, "The data is written into an internal buffer, and 
then written to the underlying stream if the buffer reaches its capacity..."
This seems to infer that the BufferedOutputStream behavior changed in JDK 
1.2 to match the described behavior of BufferedWriter (i.e. flush on fill).

Note that the Java Language Spec is not particularly clear and 
simply says "flushed as necessary" for BufferedOutputStream.  I realize it
could also be argued that the JCL & JDK 1.2 are simply wrong and should 
be ignored.

I'd be interested in hearing others' opinions (and if your observed VM 
behavior was on JDK 1.2; that would be interesting input if available).

I've checked around a bit and it seems that the typical behavior in 
*non*-Java buffering schemes is as you describe (i.e. flush on overflow 
rather than upon reaching capacity), so there is reasonable precedent 
for your requested behavior.

So folks, anyone have opinions/justifications either way?  Is the JDK 1.1
doc'ed behavior the way to go (BufferedOutputStream flush on overflow;
BufferedWriter flush on fill)?  Or the JDK 1.2 doc'ed behavior (flush on
fill for both)?  Or neither (flush on overflow for both)?  I'm interested 
in hearing the different points of view on this.  If you supply empirical 
evidence, please note whether it is version 1.1.* or 1.2 of the JDK.

Thanks in advance and John-Marc, thanks for finding this!

Warren Levy
Cygnus Solutions, Sunnyvale, CA  USA


On Mon, 21 Jun 1999 jmc@cmpharm.ucsf.edu wrote:

> I noticed that the write(byte[]) method of BufferedOutputStream
> flushes immediately upon filling up the buffer; in a JVM (and
> when using the write(byte) method), it doesn't flush until the next
> write.  As they say, "If it's yellow let it mellow..."  Although
> real apps shouldn't depend on either behavior, here is a patch
> to make libgcj behave the same way a JVM does.  I also confirmed
> that BufferedWriter does not have the same bug:
> 
> 
> diff -r -u libgcj-snapshot-1999-06-18.orig/libjava/java/io/BufferedOutputStream.java libgcj-snapshot-1999-06-18/libjava/java/io/BufferedOutputStream.java
> --- libgcj-snapshot-1999-06-18.orig/libjava/java/io/BufferedOutputStream.java
> Mon Jun 21 10:16:56 1999
> +++ libgcj-snapshot-1999-06-18/libjava/java/io/BufferedOutputStream.java
> Mon Jun 21 10:23:19 1999
> @@ -56,7 +56,7 @@
>      throws IOException, NullPointerException, IndexOutOfBoundsException
>    {
>      // If LEN < 0 then the downstream write will fail for us.
> -    if (len >= 0 && count + len < buf.length)
> +    if (len >= 0 && count + len <= buf.length)
>        {
>         System.arraycopy(b, off, buf, count, len);
>         count += len;
> 
> JMC
> -- 
> John-Marc Chandonia (jmc@cmpharm.ucsf.edu)              We're everywhere...
> Cohen Lab, University of California San Francisco       for your convenience.
> http://yuri.harvard.edu/~jmc                                -- Psi Corps <*>
>