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"?