Thomas Hallgren wrote on 05/07/2009 10:05:50 AM:
> Personally, I see this as a missing part of an otherwise good tool.
> Pack200 should have an option or something to control this. One way
> to overcome this deficiency is to check if a file is missing .class
> files and when that happens, change the magic. I've tried that, and
> it seems to work just fine.
Yes, it's really suprising that they
would *default* to being incompatible with Java 5, but I guess that's what
we're stuck with. On the other hand, there is very little value packing
a JAR file that doesn't contain any class files, since the pack200 compression
is strictly dealing with class file compression. In this case you're paying
the deflate/inflate performance cost without any transfer improvement.
Hacking the magic seems a bit scary,
in case there are any incompatible changes in the format we don't know
about. A possible safer hack would be to check the magic and delete the
packed file if the magic started with "CAFED00D/160" (gotta love
those Java magic numbers). This would imply the file contains no class
files (or pure Java 6 content, which I doubt is true for many Galileo bundles).