RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9]

[Lance Andersen]

On Wed, 21 May 2025 12:58:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Lance/Henry,
>> 
>>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
>> 
>> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 
>> 
>> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.
>
>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
> 
> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).
> 
> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.

> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions)

Any warnings should result in a non-zero for a return code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100377057