From: Warren Levy <warrenl@cygnus.com>
To: jmc@cmpharm.ucsf.edu
Cc: java-discuss@sourceware.cygnus.com, mauve-discuss@sourceware.cygnus.com
Subject: Re: BufferedOutputStream patch
Date: Wed, 23 Jun 1999 18:08:00 -0000 [thread overview]
Message-ID: <Pine.SOL.3.91.990623162940.23987I-100000@fencer.cygnus.com> (raw)
In-Reply-To: <199906212330.QAA386712@arthur.ucsf.edu>
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 <*>
>
next parent reply other threads:[~1999-06-23 18:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199906212330.QAA386712@arthur.ucsf.edu>
1999-06-23 18:08 ` Warren Levy [this message]
1999-06-23 18:15 ` Archie Cobbs
1999-06-23 20:10 ` Per Bothner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.SOL.3.91.990623162940.23987I-100000@fencer.cygnus.com \
--to=warrenl@cygnus.com \
--cc=java-discuss@sourceware.cygnus.com \
--cc=jmc@cmpharm.ucsf.edu \
--cc=mauve-discuss@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).