FULL PRODUCT VERSION :
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

A DESCRIPTION OF THE PROBLEM :
When a jar has resources and class files in it. and those resources are first encountered when packing and those are quite big (larger then the segmentLimit field of the PackerImpl class) then if there is a partialFlush: flushPartial(out, (int) Math.ceil(segsToDo));

that will ask the Package:

	    // Must choose an archive version; PackageWriter does not.
	    if (pkg.package_majver <= 0)  pkg.choosePackageVersion();


to choose the package version..
That will end up in the
 int getHighestClassVersion() {
	int res = 0;  // initial low value
	for (Iterator i = classes.iterator(); i.hasNext(); ) {
	    Class cls = (Class) i.next();
	    int ver = cls.getVersion();
	    if (res < ver)  res = ver;
	}
	return res;
    }

of the Package class but there are no classes yet enountered! so it defaults to java 6:

	int classver = getHighestClassVersion();
	if (classver != 0 &&
	    (classver >>> 16) < JAVA6_MAX_CLASS_MAJOR_VERSION) {
	    // There are only old classfiles in this segment.
	    package_majver = JAVA5_PACKAGE_MAJOR_VERSION;
	    package_minver = JAVA5_PACKAGE_MINOR_VERSION;
	} else {
	    // Normal case.  Use the newest archive format.
	    package_majver = JAVA6_PACKAGE_MAJOR_VERSION;
	    package_minver = JAVA6_PACKAGE_MINOR_VERSION;
	}


because the return will be 0..

This is wrong in my eyes. also what happens if there is just a portion of the classes hit and they are all java version X but then on other down the line is java version Y ...

it seems to me that the Packer first has to scan all the jar entries and check all the classes before it can write out anything...



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
It occurs everytime for the same jar if the jar has resources that are big and because of that it flushes them out first before testing any classes.

For example i have jars with some native libs that are large, they are encountered and flushed first.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
that Pack200 generates java5 compatible pack files if there are only java5 classes.


ACTUAL -
a java 6 pack file that bombs out on java 5 jre (like a java5 webstart)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
the current work around seems to be to jar the jar again and the first add the classes so that they are found earlier then the resources.. That seems to help.