ZipInputStream brokenness

[Jeff Sturm]

On Mon, 2 Sep 2002, Jesse Rosenstock wrote:
> Per> Adam Megacz wrote:
> Per> > If you want buffering, you should wrap a BufferedInputStream around
> Per> > it.   Buffering can be added, but not removed, which is why it is not
> Per> > automatic.
> Per>
> Per> I interpreted Jeff's message that Sun's code *does* do the byffering,
> Per> in which we should probably also do it.
> Per>
> Per> Besides, I don't see any reason that you'd ever want to *not* buffer,
> Per> at least when using a FileInputStream,.
>
> I thought Jeff was talking about ZipFile's use of a RandomAccessFile,

Correct.  The test code I posted performs exactly one read from that
InputStream.  The other 65,000 or so are from within the jar URL handler
(java.util.zip etc.).

Per, I honestly didn't try Sun's JDK, partly because alpha-linux doesn't
have a port.  Here's a comparable run with IBM's JDK 1.3:

execve("/opt/java/bin/java", ["java", "J"], [/* 24 vars */]) = 0
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 46.44    0.027492          48       569         2 read
 19.32    0.011437           2      6093           sched_yield

(The sched_yield count is intriguing, but probably has nothing to do with
zip files.)  Anyhow, it seems the JDK *must* have a fast zip file reader,
since the bytecode classloader relies on it to load 100's or perhaps
1000's of classes at startup.

> and that the solution would be to use mmap either by writing native
> code for ZipFile, or implementing java.nio and having ZipFile use that.

Interesting idea.  How far along is the java.nio code in classpath?  I've
never looked at it before.

Jeff