Why are manifest files compressed by default?

[Martin Buchholz]

Some of us at Google are having growing doubts about the compression
of zip file entries.

Compression works best when a lot of data is digested, allowing the
compression engine to do "common bit-sequence elimination".  But each
zip entry is compressed separately, and many zip entries are small.

The manifest is special not only because it is likely to be small but
because it may be read by many programs that are only interested in
zip file metadata (like the java launcher itself!), so its contents
are more likely to be read than other entries.

I guess the jar command has only one flag -0 to choose compression for
all entries, and it would be surprising for the JDK to override the
user's choice?

Maybe the default behavior should be for the JDK to automatically
choose compression only when there's a significant win, e.g. if the
entry data is sufficiently large and compressible?  Maybe the jar
command should grow other compression-related options, and -9 could
ask for "maximal overall compression"?