John Arthorne wrote:
Consider the case when you have nested jars. The top container has no
class files, so it still defaults to Java 6. All your nested content
needs packing though, so you cannot leave your top jar unpacked. If you
do, the nested packs will never be discovered.
Thomas Hallgren wrote on 05/07/2009 10:05:50 AM:
> Personally, I see this as a missing part of an otherwise good
> Pack200 should have an option or something to control this. One
> to overcome this deficiency is to check if a file is missing
> files and when that happens, change the magic. I've tried that,
> 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
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
is strictly dealing with class file compression. In this case you're
the deflate/inflate performance cost without any transfer improvement.
Again, this won't work if you have nested jars. With no nesting and no
.class files, there's really no reason to pack.
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