RFR: 8321139: jlink's man page does not document the --compress option correctly [v7]

[Jaikiran Pai]

On Tue, 25 Nov 2025 17:41:27 GMT, Ana Maria Mihalceanu <duke at openjdk.org> wrote:

>> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`:
>> 
>> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user.
>> - When an user provides `-c zip-[0-9]` to `jlink`, then the tool should process it as when receiving `--compress=zip-[0-9]`.
>> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`.
>> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release.
>> 
>> Some implementation details and choices:
>> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options.
>> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes).
>> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests.
>
> Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test for invalid values from TaskHelperTest to JLinkTest.

test/jdk/tools/jlink/JLinkTest.java line 361:

> 359:         }
> 360: 
> 361:         // short command  without argument- JDK-8321139

We don't usually include JBS bug ids in code comments. For tests which are related to a bug fix, like this one, we include the bug id in the `@bug` tag of the test definition https://openjdk.org/jtreg/tag-spec.html.

This `JLinkTest`, unfortunately has a pre-existing problem that it uses `@bug` more than once (which as per the `@bug` tag specification, isn't correct). So you will have to do some extra work with this one and address that part too. Ultimately, for this test, the `@bug` should now be:


@bug 8189777 8194922 8206962 8240349 8321139

While at it, please also update the `@bug` line in `TaskHelperTest` to include 8321139.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28359#discussion_r2563227397