On Mon, 12 Sep 2022 10:48:16 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> I have been looking into `make clean-images images` performance, and
>> realized jmod keeps compressing files with default compression level. Tuning
>> that toward lighter compression levels improves build performance
>> considerably, without a heavy loss in *.jmod sizes.
>>
>> This PR allows JMOD to select the compression level. Follow-ups would use
>> this in the build system, see #10214.
>>
>> This change nominally requires CSR, but I would like to gauge the reaction
>> to this patch first, before submitting a formal CSR. The interesting
>> asymmetry against `jlink` is: `jlink` provides `--compress` option that only
>> takes `2` for "ZIP compression". (Separately, we could argue if it would be
>> beneficial to add `--compression-level` to `jlink` as well, so to select the
>> compression level there too.)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains three additional
> commits since the last revision:
>
> - Only accept --compression-level when creating the archive
> - Merge branch 'master' into JDK-8293499-jmod-compression-level
> - Fix
src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 120:
> 118: err.date.out.of.range=--date {0} is out of the valid range
> 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
> 119: err.compression.level.out.of.range=--compression-level {0} is out of the
> valid range: 0-9
> 120: err.compression.level.wrong.mode=--compression-level {0} is only
> accepted with create mode
Hello Aleksey, the place where this error message gets used doesn't right now
pass the compression-level value to the constructor of `CommandException`. So I
guess this usage of `{0}` here is unintentional?
-------------
PR: https://git.openjdk.org/jdk/pull/10213
