On Tue, 20 May 2025 22:00:39 GMT, Henry Jen <henry...@openjdk.org> wrote:
>> Yes I understand and currently we have no documentation as to what the >> return values might be. An inconsistency in the order should also be 1 >> based we only return a 0 if there are no issues. Any warning should be >> treated the same >> >> My point is that it is worth considering with these changes > > 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. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100203673
