Community
Participate
Working Groups
Build Identifier: 1.7.0.M1 when trying to pack jar's the Jar Packer 'pack200' reports the following [pack200] Jan 18, 2012 8:53:44 AM com.sun.java.util.jar.pack.Utils$Pack200Logger warning [pack200] Warnung: Passing class file uncompressed due to unrecognized attribute: noname/DelayTimerTest.class the classification 'warning' is wrong, however, because it does not pack at all. This message is printed for every classfile compiled and in the respective JARs (usually hundreds of them). Reproducible: Always Steps to Reproduce: 1. compile the files using iajc 2. put in a jar 3. try to pack them
It is likely that every class that has gone through the compiler will have these attributes in them. I found some basic pack200 doc which I've included below. If you aren't going to use these types to drive LTW you could probably use the strip option. Or I guess you could use the pass-file option but I imagine that would defeat part of the purpose of the pack. But, as you say, I'm not sure why it reports a warning and still fails to pack - are you sure there isn't an error hidden amongst the many many warnings? ------ http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html ======== 5. Handling unknown attributes: Pack200 deals with standard attributes defined by the Java Virtual Machine Specification, however compilers are free to introduce custom attributes. When such attributes are present, by default, Pack200 passes through the class, emitting a warning message. These "passed-through" class files, may contribute to bloating of packed files. If the unknown attributes are prevalent in the classes of a JAR file, this may lead to a very large bloat of the packed output. In such a cases, consider the following strategies: Strip the attribute if the attribute is deemed to be redundant at runtime, this can be achieved by setting the property Pack200.Packer.UNKNOWN_ATTRIBUTE=STRIP or pack200 --unknown-attribute=strip foo.pack.gz foo.jar If the attributes are required at runtime, and they do contribute to an inflation, then identify the attribute from the warning message and apply a suitable layout for these, as described in the Pack200 JSR 200 specification., and the Java API reference section for Pack200.Packer. Its possible that a compiler could define an attribute not implemented in the layout specification of Pack200, and may cause the Packer to malfunction, in such cases an entire class file(s) can be "passed through", as if it were a resource by virtue of its name and can be specified as follows: pack200 --pass-file="com/acme/foo/bar/baz.class" foo.pack.gz foo.jar or an entire directory and its contents, pack200 --pass-file="com/acme/foo/bar/" foo.pack.gz foo.jar ========
Hello Andy, thanks for your hint. The Packer now warns that these unknown data is skipped, but seems to work. It is an important part, as we use Java Web Start, and our main JAR has a size of 14.6 MB uncompressed, but only 4 MB compressed. One point remains: what will the reaction of the AOP-weaver or runtime be, if the class names are stripped? Regards, Thomas Nagel
if you are stripping the attributes, it just means the weaver won't realise when it sees an aspect (for example), it will just think it is a class. If you passed those classes to a loadtime weaver and had told the weaver 'type X is an aspect' you would likely see a 'type X is not an aspect' error message come out, if the attributes had been stripped. But if you aren't weaving, the code will run just fine.
