SUGGESTED FIX

The comparison that fails compares a long with an int, which gets sign-extended to a long and becomes negative.  To use this as a 32-bit unsigned integer in src/share/classes/java/util/zip/ZipInputStream.java in method readEnd:

$ sccs diffs -C src/share/classes/java/util/zip/ZipInputStream.java

------- ZipInputStream.java -------
*** /tmp/sccs.0maGmG    Mon Dec 29 13:43:28 2008
--- src/share/classes/java/util/zip/ZipInputStream.java Mon Dec 29 09:58:23 2008
***************
*** 368,374 ****
                  e.size = get32(tmpbuf, EXTLEN);
              }
        }
!       if (e.size != inf.getTotalOut()) {
            throw new ZipException(
                "invalid entry size (expected " + e.size + " but got " +
                inf.getTotalOut() + " bytes)");
--- 368,374 ----
                  e.size = get32(tmpbuf, EXTLEN);
              }
        }
!       if (e.size != (inf.getTotalOut() & 0xFFFFFFFFL) ) {
            throw new ZipException(
                "invalid entry size (expected " + e.size + " but got " +
                inf.getTotalOut() + " bytes)");
                                     

EVALUATION

Only an issue in 1.4.2 because Inflater.getTotalOut() returns an int.  In 5.0 onwards, we use Inflater.getBytesWritten() which returns a long.
                                     

EVALUATION

The evaluation of bug 4262583 describes the issue, and the solution which (IIRC) was used in the fix for JDK 1.5.  In particular, it notes:

<snip>
One very good reason to fix this is that currently a user can use the "jar"
command to create a jar file that cannot be read by "jar".
</snip>