Update readme (#395)

* update readme

* update guava

* Update Futures.java

* Update MoreExecutors.java

* Update NachoSpigot-API/src/main/java/com/google/common/util/concurrent/MoreExecutors.java

Co-authored-by: Elier <[email protected]>

NachoSpigot-API/pom.xml

@@ -48,7 +48,7 @@
             <groupId>com.google.guava</groupId>
             <artifactId>guava</artifactId>
             <!-- Update modified guava classes when updating -->
-            <version>31.0.1-jre</version>
+            <version>31.1-jre</version>
             <scope>compile</scope>
         </dependency>
         <dependency>

NachoSpigot-API/src/main/java/com/google/common/util/concurrent/Futures.java

@@ -172,7 +172,11 @@ private Futures() {}
    * @since 14.0
    */
   public static <V extends @Nullable Object> ListenableFuture<V> immediateCancelledFuture() {
-    return new ImmediateCancelledFuture<V>();
+    ListenableFuture<Object> instance = ImmediateCancelledFuture.INSTANCE;
+    if (instance != null) {
+      return (ListenableFuture<V>) instance;
+    }
+    return new ImmediateCancelledFuture<>();
   }
 
   /**

NachoSpigot-API/src/main/java/com/google/common/util/concurrent/MoreExecutors.java

@@ -440,14 +440,22 @@ public static ListeningExecutorService newDirectExecutorService() {
      * difficult to reproduce because they depend on timing. For example:
      *
      * <ul>
-     *   <li>A call like {@code future.transform(function, directExecutor())} may execute the function
-     *       immediately in the thread that is calling {@code transform}. (This specific case happens
-     *       if the future is already completed.) If {@code transform} call was made from a UI thread
-     *       or other latency-sensitive thread, a heavyweight function can harm responsiveness.
-     *   <li>If the task will be executed later, consider which thread will trigger the execution --
-     *       since that thread will execute the task inline. If the thread is a shared system thread
-     *       like an RPC network thread, a heavyweight task can stall progress of the whole system or
-     *       even deadlock it.
+     *   <li>When a {@code ListenableFuture} listener is registered to run under {@code
+     *       directExecutor}, the listener can execute in any of three possible threads:
+     *       <ol>
+     *         <li>When a thread attaches a listener to a {@code ListenableFuture} that's already
+     *             complete, the listener runs immediately in that thread.
+     *         <li>When a thread attaches a listener to a {@code ListenableFuture} that's
+     *             <em>in</em>complete and the {@code ListenableFuture} later completes normally, the
+     *             listener runs in the the thread that completes the {@code ListenableFuture}.
+     *         <li>When a listener is attached to a {@code ListenableFuture} and the {@code
+     *             ListenableFuture} gets cancelled, the listener runs immediately in the the thread
+     *             that cancelled the {@code Future}.
+     *       </ol>
+     *       Given all these possibilities, it is frequently possible for listeners to execute in UI
+     *       threads, RPC network threads, or other latency-sensitive threads. In those cases, slow
+     *       listeners can harm responsiveness, slow the system as a whole, or worse. (See also the
+     *       note about locking below.)
      *   <li>If many tasks will be triggered by the same event, one heavyweight task may delay other
      *       tasks -- even tasks that are not themselves {@code directExecutor} tasks.
      *   <li>If many such tasks are chained together (such as with {@code
@@ -463,9 +471,11 @@ public static ListeningExecutorService newDirectExecutorService() {
      *       terminate whichever thread happens to trigger the execution.
      * </ul>
      *
-     * Additionally, beware of executing tasks with {@code directExecutor} while holding a lock. Since
-     * the task you submit to the executor (or any other arbitrary work the executor does) may do slow
-     * work or acquire other locks, you risk deadlocks.
+     * A specific warning about locking: Code that executes user-supplied tasks, such as {@code
+     * ListenableFuture} listeners, should take care not to do so while holding a lock. Additionally,
+     * as a further line of defense, prefer not to perform any locking inside a task that will be run
+     * under {@code directExecutor}: Not only might the wait for a lock be long, but if the running
+     * thread was holding a lock, the listener may deadlock or break lock isolation.
      *
      * <p>This instance is equivalent to:
      *
@@ -1169,4 +1179,4 @@ public static ListeningExecutorService sameThreadExecutor() {
         return newDirectExecutorService();
     }
     // Nacho end
-}
+}

README.md

@@ -1,4 +1,4 @@
-# NachoSpigot [![GitHub Workflow Status](https://img.shields.io/github/workflow/status/CobbleSword/NachoSpigot/NachoSpigot%20Build)](https://nightly.link/CobbleSword/NachoSpigot/workflows/build-nachospigot/master/NachoSpigot-server.zip)
+# NachoSpigot [![GitHub Workflow Status](https://github.com/CobbleSword/NachoSpigot/actions/workflows/build-nachospigot.yml/badge.svg)](https://nightly.link/CobbleSword/NachoSpigot/workflows/build-nachospigot/master/NachoSpigot-server.zip)
 
 NachoSpigot offers a number of enhancements to performance as well as bug fixes and being able to perform well with a large number of players.
 
@@ -15,7 +15,7 @@ If this ever causes issues, we can disable this and hope none of this ever happe
 ## Current State
 Java 17 (LTS) is the recommended version to use, otherwise Java 11 is fine. Java 8 works, but is not recommended due to security issues.
 
-**NachoSpigot supports Java 8 to Java 17!**
+**NachoSpigot supports Java 8 to Java 18!**
 
 Nacho can be used in production environments with a good degree of stability.