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
