On Wed, 21 May 2025 12:58:37 GMT, Jaikiran Pai <j...@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
