Update README.md

Author: q3769

README.md

@@ -1,3 +1,4 @@
+
 [![Maven Central](https://img.shields.io/maven-central/v/io.github.q3769/conseq4j.svg?label=Maven%20Central)](https://search.maven.org/search?q=g:%22io.github.q3769%22%20AND%20a:%22conseq4j%22)
 
 # conseq4j
@@ -93,16 +94,12 @@ public interface ExecutorServiceFactory {
 }
 ```
 
-This API style loosely takes the form of "thread affinity". Sequence keys are used to summon executors of JDK
-type [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html). The same
-sequence key always gets back the same sequential executor. All tasks of that sequence key can then be "affined" to and
-executed sequentially by the summoned executor in the same submission order.
+This API style loosely takes the form of "thread affinity". Sequence keys are used to summon executors of the [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) JDK
+type. The same sequence key always gets back the same sequential executor. All tasks of that sequence key can then be "affined" to and executed sequentially by the summoned executor in the same submission order.
 
-The total number of executors concurrently available at runtime is configurable. As each executor is sequential, the
-number of available executors equals the number of tasks that can be executed in parallel.
+The total number of executors concurrently available at runtime is configurable, and default to the available runtime processors of the JVM. Since each executor is sequential, the number of available executors equals the number of tasks that can be executed in parallel.
 
-Consider using this style when the summoned executor needs to provide
-the [syntax and semantic richness](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html#method.summary)
+Consider using this style when the summoned executor needs to provide the [syntax and semantic richness](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html#method.summary)
 of the JDK `ExecutorService` API.
 
 - Sample usage
@@ -148,18 +145,11 @@ As with hashing, collision may occur among different sequence keys. When hash co
 sequence keys are assigned to the same executor. Due to the single-thread setup, the executor still ensures the local
 sequential execution order for each individual sequence key's tasks. However, unrelated tasks of different sequence
 keys now assigned to the same bucket/executor may delay each other's execution inadvertently while waiting in the
-executor's task queue. Consider this a trade-off of the executor's having the same syntax and semantic richness as a
-JDK [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html).
+executor's task queue. Consider this a trade-off of getting the syntax and semantic richness of the JDK [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html).
 
-To account for hash collision, conseq4j Style 1 does not support any shutdown action on the API-provided
-executor ([ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html))
-instance. That is to prevent unintended task cancellation across different sequence keys.
-The [Future](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html) instance(s) subsequently
-returned by the executor, though, is still cancellable. The hash collision may not be an issue for workloads that are
-asynchronous and focused on overall through-put, but is something to be aware of.
+To account for hash collision, this `conseq4j` style does not support any shutdown action on its provided executor ([ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html)) instances (It'd throws a runtime exception). That is to prevent unintended task cancellation across different sequence keys in the same bucket. The [Future](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html) instances subsequently produced by the executor, however, are still cancellable. The hash collision may not be an issue for workloads that are asynchronous and focused on overall through-put, but is something to be aware of.
 
-The default general concurrency is the JVM
-run-time's [availableProcessors](https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#availableProcessors--):
+The default general concurrency is the JVM run-time's [availableProcessors](https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#availableProcessors--):
 
   ```jshelllanguage
   ConseqFactory.instance();
@@ -208,12 +198,8 @@ This API style is more concise. Bypassing the JDK ExecutorService API, it servic
 execution semantics holds: Tasks of the same sequence key are executed in the same submission order; tasks of different
 sequence keys are managed to execute in parallel.
 
-For versions requiring Java 21+, conseq4j Style 2 defaults to have no preset limit on the overall concurrency when
-executing tasks; for other versions, this style's default concurrency is the number of JVM run-time'
-s [availableProcessors](https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#availableProcessors--). Prefer
-this style when the full-blown syntax and semantic support of
-JDK [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) is not
-required.
+For versions requiring Java 21+, this `conseq4j` style defaults to have no preset limit on the overall concurrency when
+executing tasks; for other versions, this style's default concurrency is the number of JVM run-time [availableProcessors](https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#availableProcessors--). Prefer this style when the full-blown syntax and semantic support of JDK [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html) is not required by the use case.
 
 - Sample usage
 
@@ -244,17 +230,12 @@ public class MessageConsumer {
 }
 ```
 
-The implementation relies on
-JDK's [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) to
-achieve sequential execution of related tasks. One single pool of threads is used to facilitate the overall
-asynchronous execution. The concurrency to execute unrelated tasks is generally limited only by the backing work
-thread pool's capacity, or unlimited in the case of default/virtual thread mode.
+The implementation relies on JDK's [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) to achieve sequential execution of related tasks. One single pool of threads is used to facilitate the overall asynchronous execution. The concurrency to execute unrelated tasks is generally limited only by the backing work thread pool's capacity, or "unlimited" in the case of the default/virtual thread mode.
 
 Instead of thread-affinity or bucket hashing, tasks are decoupled from their execution threads. All pooled threads are
 anonymous and interchangeable to execute any tasks. Even sequential tasks of the same sequence key may be executed by
-different threads, albeit in sequential order. When the work thread pool has idle threads available, a task awaiting
-execution must have been blocked only by its own related task(s) of the same sequence key - as is necessary, and not
-by unrelated tasks of different sequence keys in the same "bucket" - as is unnecessary. This can be a desired
+different threads, albeit in sequential order. When the work thread pool has idle threads available, yet a task is still awaiting
+execution, then the task must have been blocked only by its own related task(s) of the same sequence key - as is necessary, and not by unrelated tasks of different sequence keys in the same "bucket" - as is unnecessary. This can be a desired
 advantage over the thread-affinity API style, at the trade-off of lesser syntax and semantic richness than the
 JDK [ExecutorService](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html).
 
@@ -297,18 +278,17 @@ out of order in a globally concurrent process. This implies:
 received.
 
 (3) The message consumer ensures that related messages are processed in the same order, e.g. by using a
-sequence/correlation key as with this API.
+sequence/correlation key, as with the `conseq4j` API.
 
 ### 2. Curative
 
 This is more on the business rule level. Sometimes preventative measures are either not possible or not worthwhile to
 pursue. By the time messages arrive at the consumer, they may be intrinsically out of order. E.g. when the messages are
-coming in from independent producers and sources, there may be no guarantee of correct ordering in the first place. In
-such cases, the message consumer may be able to take a curative approach, by applying business rules to restore
+coming in from independent producer and source systems, there may be no guarantee of correct ordering in the first place. In such cases, the message consumer may be able to take a curative approach, by applying business rules to restore
 necessary order and properly handle the out-of-order messages.
 
 Compared to preventative measures, corrective ones can be much more complicated in terms of design, implementation and
-runtime performance. E.g. for each incoming event, it may help to do a stateful/historical look-up of all the data and
+runtime performance. E.g. for each incoming event, it may help to perform a stateful/historical look-up of all the data and
 other events that are related; this forms a correlated and collective information session of the incoming event. A
 comprehensive review of such session can detect and determine if the incoming event is out of order per business rules;
 corrective measures can then be taken to restore the right order, among other reactive actions. This may fall into the