I'm actually waiting for an email reply from this guy; unless you understand what he's talking about here and see the bug ( I'm now uncertain ), email me ( hagen ) to find out if we have a reply yet.

From: Dan Jacobs <###@###.###>
This does not look like form output to me.


Dear java bugsters,

I submitted a previous bug report that claimed there was a bug in
ZipInputStream, but I was wrong. The bug is in ClassPath.getFiles().

The following code illustrates the problem. The value of pathname
should be something like "java/lang" on Solaris, indicating a package
in a zip file.

        Enumeration allClassFiles = theClassPath.getFiles(pathname, "class");
        while (allClassFiles.hasMoreElements()) {
            sun.tools.java.ClassFile classFile =
                (sun.tools.java.ClassFile)allClassFiles.nextElement();

            /* if you leave this out, it will break */
            if (classFile.isZipped()) {
                String pathSep = System.getProperty("path.separator");
                String filePathname = pathname + pathSep + classFile.getName();
                classFile = CLASSPATH.getFile(filePathname);
            }

            DataInputStream dstream =
                new DataInputStream(classFile.getInputStream());

            int magicNumber = dstream.readInt();
            if (magicNumber != 0xCafeBabe)
            {
                System.out.println("Lossage!");
            }
        }

From: Dan Jacobs <###@###.###>
This does not look like form output to me.


Dear Sun bugsters,

I've run into a couple of problems with ZipInputStreams, described below.
I'm running the JDK 1.0 release in Windows NT 3.51.

I don't know if I should try to hide the fact that I'm using Sun internal
classes without a license (they're not *that* easy to reverse engineer),
but I thought you'd want these classes to work the way they should :-).

BTW, if there's a better way for me to read class files than to use Sun's
internal classes, I'd love to know about it!

1. sun.tools.java.ClassFile.getInputStream() returnns a ZipInputStream
    that is positioned short of the beginning of the actual file's contents
    by the length of the zip-entry's pathname. The length, however, is
    correct so attempting to work around the incorrect offset just runs
    into a spurious end-of-file.

2. ZipInputStreams, when used in conjunction with DataInputStreams, read
    twice as many bytes as they should for methods such as skipBytes() and
    read(byte[]).