[MJLINK-77] accept JDK21+ compress parameters

[bmarwell]

This one needs a description. This PR changes the behaviour in a way that valid values will be checked according to the JDK 21 help. However, it would let values like zip-6 pass for JDK < 21, which is not a valid value for JDK 9 through 20.

So, I was thinking, maybe not to check the parameters for validity at all OR extend the check. However, I would vote to drop the checks alltogether, because future jlink versions could accept zstd-6 or zst-6 as valid value, as well as other compression formats or number systems (like arabic). But since this would have been a change in behaviour AND easier to implement, I started with this version.

My -1, Let's get rid of the duplicate parameter checks. Just pass the user input to jlink.

---

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MJLINK-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MJLINK-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[bmarwell]

I cannot create a test for JDK21, because of the way too old spotless version. :( Need to wait to have #180 merged first, then rebase this PR.

[rmannibucau]

What about dropping all exploded options from the mojo and just pass args to jlink, otherwise we'll keep running on this kind of issues and the actual wrapping of all options has very few values (had the exact same issue with graalvm and getting rid of the mojo mapping made the maintenance easier without bringin any issue to end users in terms of usage).

[bmarwell]

What about dropping all exploded options from the mojo and just pass args to jlink, otherwise we'll keep running on this kind of issues and the actual wrapping of all options has very few values (had the exact same issue with graalvm and getting rid of the mojo mapping made the maintenance easier without bringin any issue to end users in terms of usage).

Two obvious disadvantages:

• Hard breaking change, unless we carry over existing options for a while
• no completion, docs, whatsoever.

We could add String[] args as a feature in a later version, like the compile plugin has, but keep the current options. This would allow both ways. WDYT?

[rmannibucau]

We could add String[] args as a feature in a later version, like the compile plugin has, but keep the current options. This would allow both ways. WDYT?

well think compiler is one good example of why a hybrid mode is bad, you get the worse of both worlds and mess up the completion with concurrent options you never detect - exactly the issue you are trying to fix.
So, for me, it is mainly a matter of willing to enable the user to use the tool we wrap or just to limit its usage to a few options we assume which will not break (no strong preference on jlink due my almost zero usage).

[bmarwell]

@rmannibucau I think that's a fundamental plugin policy discussion which should go onto the mailing list. For now, we should review the changes at hand. My open question is: Should we validate here at all, see PR description.

[rmannibucau]

@bmarwell if you dont passthru you know so you validate and forbid future usage until the plugin is upgraded IMHO otherwise it does not make sense to make it specific.

[slawekjaranowski]

groovy has a assert statement, code can look better with it

[slawekjaranowski]

I'm for simplify code and pass parameter as it to external tools

[bmarwell]

I'm for simplify code and pass parameter as it to external tools

Yes, see #183. Closing this one, we all agree on it.