I'll go ahead with this enhancement, and make sure the wording is open
to adding validation logic not related to multi-release jars in the future.
Jorn
On 12/05/2021 14:47, Jorn Vernee wrote:
On 12/05/2021 14:41, Alan Bateman wrote:
On 12/05/2021 11:58, Jorn Vernee wrote:
Hi,
I see that the jar tool has validation logic for multi-release jars
that is triggered when creating or updating a jar that has a
versioned file as an input. I wanted to ask what people think about
the idea of exposing this validation logic directly under a
--validate command line flag as well.
Malformed multi-release jars can cause compilation and runtime
problems because the API exposed by the jar is different across
different Java versions. Exposing the validation logic directly
would allow for easy validation of jar files that are suspected of
being malformed multi-release jars.
The validation logic is already cleanly separated into a separate
Validator class in the source code, and adding a command line flag
that exposes it directly is a relatively minimal change [1]. It
seems like maybe the intent in the past was also to expose this
validation logic directly?
What's the history here? Any opinions about exposing this validation
logic through a command line option?
I think it could be useful, esp. if Maven or Gradle plugins could
make use of it.
There is other validation that could be done. JDK-8207339 is one
example where it would be useful to identify a JAR file with a
services configuration file that disagrees with the module
definition. I bring it up because a general --validate option could
do more than the fingerprint check. If the intention is to limit it
to MR JAR features then I think it will need a different and more
specific option name.
Potentially doing other validation seems like a good idea to me as
well. It seems like the validation logic could be expanded further in
the future. I brought up multi-release jars because AFAICS that's the
only thing the existing validation logic concerns itself with, but I
don't see any reason why validation that doesn't relate to
multi-release jars couldn't be added as well (and I guess I chose the
name --validate for that reason :) )
Jorn
