ZipInputStream brokenness

[Per Bothner]

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/