Trivial patches for typos in java.base

[Anthony Vanelverdinghe]

Hi

I filed 2 bug reports for typos in java.base Javadoc:

https://bugs.openjdk.java.net/browse/JI-9064752 with patch

diff --git 
a/src/java.base/share/classes/java/lang/invoke/package-info.java 
b/src/java.base/share/classes/java/lang/invoke/package-info.java
index 82600d4866..a0ad09b03e 100644
--- a/src/java.base/share/classes/java/lang/invoke/package-info.java
+++ b/src/java.base/share/classes/java/lang/invoke/package-info.java
@@ -31,7 +31,7 @@
   * As described in the Java Virtual Machine Specification, certain 
types in this package
   * are given special treatment by the virtual machine:
   * <ul>
- * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle}
+ * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle} and
   * {@link java.lang.invoke.VarHandle VarHandle} contain
   * <a href="MethodHandle.html#sigpoly">signature polymorphic methods</a>
   * which can be linked regardless of their type descriptor.
@@ -190,7 +190,7 @@
   * invoked with just the parameter types of static arguments, thereby 
supporting a wider
   * range of methods compatible with the static arguments (such as 
methods that don't declare
   * or require the lookup, name, and type meta-data parameters).
- * <p> For example, for dynamically-computed call site, a the first 
argument
+ * <p> For example, for a dynamically-computed call site, the first 
argument
   * could be {@code Object} instead of {@code MethodHandles.Lookup}, 
and the return type
   * could also be {@code Object} instead of {@code CallSite}.
   * (Note that the types and number of the stacked arguments limit

and https://bugs.openjdk.java.net/browse/JI-9064753 with patch

diff --git 
a/src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java 
b/src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
index 415e50e29c..be46131d3e 100644
--- 
a/src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
+++ 
b/src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
@@ -84,7 +84,7 @@ import jdk.internal.vm.annotation.ReservedStackAccess;
   *     try {
   *       // ... method body
   *     } finally {
- *       lock.unlock()
+ *       lock.unlock();
   *     }
   *   }
   * }}</pre>

There's also a typo in a comment inside native code, but I didn't file a 
bug report for it:

diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c 
b/src/java.base/unix/native/libjava/ProcessImpl_md.c
index 9c562a3d16..68aa1c457a 100644
--- a/src/java.base/unix/native/libjava/ProcessImpl_md.c
+++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c
@@ -93,7 +93,7 @@
   *    grained control about how exactly the process fork is executed. 
It is
   *    powerful, but Linux-specific.
   *
- * Aside from these three possibilities there is a forth option: 
posix_spawn(3).
+ * Aside from these three possibilities there is a fourth option: 
posix_spawn(3).
   * Where fork/vfork/clone all fork off the process and leave pre-exec 
work and
   * calling exec(2) to the user, posix_spawn(3) offers the user 
fork+exec-like
   * functionality in one package, similar to CreateProcess() on Windows.

Kind regards,
Anthony