This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: ZipInputStream brokenness
Adam Megacz wrote:
Per Bothner <per@bothner.com> writes:
I don't think this code says very much about buffers pro or con.
Sure it does. If you have two inputstreams reading off a single
parent, and one of the children buffers, it can screw up its sibling.
The issue isn't buffering, but reading more data than "belongs to
you". A child can buffer data intended for itself, but cannot
consume data intended for its sibling. Using a BufferedReader
would make it difficult to avoid that, so it is clearly wrong.
However, there should be buffering *below* that, at the
InputStream level.
If, as you claim, buffering is Always A Good Thing,
No, of course not.
why doesn't the base InputStream class do buffering?
Because Sun screwed up? Else why the need for nio?
They forgot the lessons from C (FILE) and C++ (streams),
designing the protocol around buffers.
All I am saying is that if you open a ZipInputStream on
top of a FileInputStream or a stream created from a URL,
then *somebody* should be doing buffering (and it should be a
byte array in the Java runtime, not the OS).
A SipFile on top of a RandomAccessFile is a little harder,
but it too should be buffering the data. Probably we should
re-write RandomAccessFile to use memory mapping.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/