RFC: Add a --validate option to the jar tool

[Jorn Vernee]

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