Summary

Update the jarsigner doc to be more precise and clear.

Problem

The text (as shown in the spec below) says it is the jar tool that modified the manifest but actually it's jarsigner.

Solution

See spec.

I also take this chance to make the text more clear by adding some new and original words and rewrite some sentences.

Specification

diff --git a/closed/src/jdk.jartool/share/man/jarsigner.md b/closed/src/jdk.jartool/share/man/jarsigner.md
index a3de42272bdfa3ef30b4db55d9b7b1be9413dc23..c003b3168dbf73532cc2cdd42ea7db748e09704b 100644
--- a/closed/src/jdk.jartool/share/man/jarsigner.md
+++ b/closed/src/jdk.jartool/share/man/jarsigner.md
@@ -379,15 +379,18 @@ have changed since then. JAR file verification involves the following steps:
     Signature File.

     One reason the hash of the manifest file that is stored in the `.SF` file
-    header might not equal the hash of the current manifest file is that one or
-    more files were added to the JAR file (with the `jar` tool) after the
-    signature and `.SF` file were generated. When the `jar` tool is used to add
-    files, the manifest file is changed by adding sections to it for the new
-    files, but the `.SF` file isn't changed. A verification is still considered
-    successful when none of the files that were in the JAR file when the
-    signature was generated have been changed since then. This happens when the
-    hashes in the non-header sections of the `.SF` file equal the hashes of the
-    corresponding sections in the manifest file.
+    header might not equal the hash of the current manifest file is that it
+    might contain sections for newly added files after the file was signed. For
+    example, suppose one or more files were added to the signed JAR file (using
+    the `jar` tool) that already contains a signature and a `.SF` file. If the
+    JAR file is signed again by a different signer, then the manifest file is
+    changed (sections are added to it for the new files by the `jarsigner` tool)
+    and a new `.SF` file is created, but the original `.SF` file is unchanged. A
+    verification is still considered successful if none of the files that were
+    in the JAR file when the original signature was generated have been changed
+    since then. This is because the hashes in the non-header sections of the
+    `.SF` file equal the hashes of the corresponding sections in the manifest
+    file.

 3.  Read each file in the JAR file that has an entry in the `.SF` file. While
     reading, compute the file's digest and compare the result with the digest