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

[Henry Jen]

On Wed, 21 May 2025 20:21:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/man/jar.md line 223:
>> 
>>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
>>> 222: other than the `jar` command. The --validate option may be used to perform the following
>>> 223: integrity checks against a jar archive:
>> 
>> Nit - "integrity checks against a JAR file:"
>
> I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file.
> 
> The man page description can use a further overhaul as we still reference applets.  So we can do this also as follow on work

I changed references in the new content and leave the retrofit to future works.

>> src/jdk.jartool/share/man/jar.md line 235:
>> 
>>> 233:   versions.
>>> 234: 
>>> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise
>> 
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
>
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
> 
> I don't have a preference but unix/MacOS commands vary:
> 
> -  ls command: The ls utility exits 0 on success, and >0 if an error occurs.
> - grep command: 
> 
>> The grep utility exits with one of the following values:
> 
>      0     One or more lines were selected.
>      1     No lines were selected.
>      >1    An error occurred.
> 
> - unzip command:
> 
>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
>        following values, except under VMS:
> 
>               0      normal; no errors or warnings detected.
> 
>               1      one or more warning errors were encountered, but processing completed successfully
>                      anyway.  This includes zipfiles where one or more files was skipped due to unsupported
>                      compression method or encryption with an unknown password.
> 
>               2      a generic error in the zipfile format was detected.  Processing may have completed
>                      successfully anyway; some broken zipfiles created by other archivers have simple work-
>                      arounds.
>               3      a severe error in the zipfile format was detected.  Processing probably failed
>                      immediately.
> 
>               4      unzip was unable to allocate memory for one or more buffers during program
>                      initialization.
> 
>               5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
>                      password(s).
> 
>               6      unzip was unable to allocate memory during decompression to disk.
> 
>               7      unzip was unable to allocate memory during in-memory decompression.
> 
>               8      [currently not used]
> 
>               9      the specified zipfiles were not found.
> 
>               10     invalid options were specified on the command line.
> 
>               11     no matching files were found.
> 
>               50     the disk is (or was) full during extraction.
> 
>               51     the end of the ZIP archive was encountered prematurely.
> 
>               80     the user aborted unzip prematurely with control-C (or similar)
> 
>               81     testing or extraction of one or more files failed due to unsupported compression methods
>                      or unsupported decryption.
> 
>               82     no files were found due to bad decryption password(s).  (If even one file is successfully
>       ...

I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.

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

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