-
Bug
-
Resolution: Duplicate
-
P4
-
1.3.1
-
sparc
-
solaris_8
Name: nt126004 Date: 08/08/2002
FULL PRODUCT VERSION :
On Solaris:
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
- and -
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
On Linux:
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)
- and -
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
FULL OPERATING SYSTEM VERSION :
SunOS host 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Blade-100
ADDITIONAL OPERATING SYSTEMS :
Linux alpha 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT 2001 i686 unknown
A DESCRIPTION OF THE PROBLEM :
After creating very large (ie, lots of entries) jar files
with the JarOutputStream, there are problems reading the
entries in them with the JarFile 'entries' enumeration method.
For example, after writing a jar file with 200000 entries,
when opening it as a JarFile and walking the 'entries'
enumeration, only 3392 entries are available. There is no
exception thrown, just an enumeration list that is way too
short.
However, reading the jar via a JarInputStream finds all
200000 entries with no problem.
This behavior is exhibited on all 1.2/1.3/1.4 Linux/Solaris
JDKs I tested, though the number of entries given in the
enumerations seems somewhat random, though usually never
more than about 45000.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. compile the given sample code
2. create a large jar with a command such as:
java -Xmx256m LargeJar test1.jar 200000
3. run the code again to read the jar as in:
java LargeJar test1.jar
EXPECTED VERSUS ACTUAL BEHAVIOR :
The sample code output is self-explanatory.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
None given.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.*;
import java.util.*;
import java.util.jar.*;
import java.util.zip.*;
public class LargeJar {
public static void main( String[] args )
throws Exception {
if ((args.length < 1) || (args.length > 2)) {
System.err.println("Create a jar with args: filename num-entries");
System.err.println(" Test a jar with args: filename");
System.exit(2);
}
// create jar if desired
if (args.length == 2) {
int size = Integer.parseInt(args[1]);
System.out.println("Writing jar file " + args[0] + " with "
+ size + " entries...");
JarOutputStream out
= new JarOutputStream(new FileOutputStream(args[0]));
byte[] junk = new byte[2345];
for (int i = 0; i < junk.length; i++) {
junk[i] = (byte)(i + (i << 2));
}
for (int i = 0; i < size; i++) {
ZipEntry entry = new ZipEntry("x" + i);
out.putNextEntry(entry);
out.write(junk);
}
out.close();
System.out.println("Done.");
return;
}
// read/test jar
System.out.println("Testing jar file " + args[0] + " ...");
JarFile jar = new JarFile(args[0]);
int size1 = 0;
Enumeration enum = jar.entries();
while (enum.hasMoreElements()) {
enum.nextElement();
size1++;
}
System.out.println("JarFile entries enumeration yielded " + size1
+ " elements.");
jar.close();
JarInputStream in = new JarInputStream(new FileInputStream(args[0]));
int size2 = 0;
ZipEntry entry;
while ((entry = in.getNextEntry()) != null) {
size2++;
}
in.close();
System.out.println("JarInputStream read yielded " + size2
+ " elements.");
if (size1 != size2) {
System.out.println("SIZES DIFFER!");
System.exit(1);
}
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
Must limit the size of jar files.
(Review ID: 160554)
======================================================================
- duplicates
-
JDK-4828461 Support Zip files with more than 64k entries
-
- Resolved
-