On Wed, 21 May 2025 12:47:00 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> 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. > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100232060
