Fix typos

Author: manuelbl

java-does-usb/jextract/README.md

@@ -17,7 +17,7 @@ The resulting code is then committed to the source code repository. Before the c
 
 - According to the jextract mailing list, it would be required to create separate code form Intel x64 and ARM64 architecture. And jextract would need to be run on each architecture separately (no cross-compilation). Fortunately, this doesn't seem to be the case. Linux code generated on Intel x64 also runs on ARM64 without change. The same holds for macOS. However, jextract needs to be run on each operating system separately.
 
-- JDK 20 introduced a new feature for saving the thread-specific error values (`GetLastError()` on Windows, `errno` on Linux). To use it, an additional parameter must be added to function calls. Unfortuntely, this is not yet supported by jextract. So with the JDK 20 updates, more code is written manually and less is generated by jextract.
+- JDK 20 introduced a new feature for saving the thread-specific error values (`GetLastError()` on Windows, `errno` on Linux). To use it, an additional parameter must be added to function calls. Unfortunately, this is not yet supported by jextract. So with the JDK 20 updates, more code is written manually and less is generated by jextract.
 
 - `typedef` and `struct`:
 
@@ -98,7 +98,7 @@ The known limitations are:
 
 *jextract* generates a comprehensive set of methods for each function, struct, struct member etc. Most of it will not be used as a typical application just uses a subset of struct members, might only read or write them etc. So a considerable amount of code is generated. For some types, it's a bit excessive.
 
-The worst example is [`IOUSBInterfaceStruct100`](https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/src/main/java/net/codecrete/usb/macos/gen/iokit/IOUSBDeviceStruct100.java) (macOS). This is a `struct` consisting of about 75 member functions. It's bascially a vtable of a C++ class. *jextract* generates the same number of classes plus a huge class for the struct itself. The total code size (compiled) for this single `struct` is over 300 kByte.
+The worst example is [`IOUSBInterfaceStruct100`](https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/src/main/java/net/codecrete/usb/macos/gen/iokit/IOUSBDeviceStruct100.java) (macOS). This is a `struct` consisting of about 75 member functions. It's basically a vtable of a C++ class. *jextract* generates the same number of classes plus a huge class for the struct itself. The total code size (compiled) for this single `struct` is over 300 kByte.
 
 The table below shows statictics for version 0.2.0 of the library:
 

java-does-usb/src/main/java/net/codecrete/usb/USBEndpoint.java

@@ -24,7 +24,7 @@ public interface USBEndpoint {
      * </p>
      * <p>
      * Use this number when calling any of the transfer methods of a
-     * {@link USBDevice} instace.
+     * {@link USBDevice} instance.
      * </p>
      *
      * @return the endpoint number

java-does-usb/src/main/java/net/codecrete/usb/macos/MacosUSBDevice.java

@@ -43,6 +43,7 @@
  * asynchronous transfer and waiting for the completion.
  * </p>
  */
+@SuppressWarnings("SynchronizationOnLocalVariableOrMethodParameter")
 public class MacosUSBDevice extends USBDeviceImpl {
 
     private final MacosAsyncTask asyncTask;