Summary

Add a command line option to the jmod tools to specify the compression level to use.

Problem

jmod is used during JDK build time to produce the .jmod files with module contents. The format for these files is deliberately unspecified. Currently, jmod compresses the module contents with ZipOutputStream with a default compression. Given the frequency of JDK (re-)builds by OpenJDK developers and build farms, it makes sense to consider alternative compression levels.

Solution

Add a new option --compress, which will be parsed and passed to internal compressor and affects the final compression level. OpenJDK and other build environments utilizing jmod tools can then leverage this option to balance build times vs module file size. To provide extensibility, the option would mention the compressor name in it, so that future work can leverage the same option for choosing the alternative compressor. We roughly follow the syntax that ZFS has for their compression options:

$ zfs set compression
...
    compression     YES      YES   on | off | lzjb | gzip | gzip-[1-9] | zle | lz4 | zstd | zstd-[1-19] | zstd-fast-[1-10,20,30,40,50,60,70,80,90,100,500,1000]
...

If we decide that jlink --compress options could do the same selection of compressors, this solution could apply there too, making jmod and jlink CLI options consistent.

Specification

$ jmod -h
  --compress <compress>               Compression to use when creating the   
                                        JMOD archive. Accepted values are:   
                                        zip-[0-9], where zip-0 provides no   
                                        compression, and zip-9 provides the  
                                        best compression. Default is "zip-6".

...where the numeric value matches the compression level of Deflater and other standard compressors: 0 means no compression, 1 means fastest compression, 9 means best compression. This applies only to "create" mode. The default setting, zip-6, matches the status quo behavior.

There should be no compatibility impact for generated files, as their format does not change. The compatibility impact for jmod uses is minimal, as the new option would not be accepted by older jmod tools, which would need script adjustments, if necessary to support both old and new jmod, while still setting up compression level if available.