starter Java 19

Author: wesleyegberto

README.md

@@ -10,6 +10,11 @@ A project to explore more about the new features of Java 8, 9, ...
 
 ## Resume by Version
 
+* [Java 19](java-19/)
+  * Virtual Thread :rocket:
+  * Pattern matching for `switch` (preview 3)
+  * Vector API (fourth incubator)
+
 * [Java 18](java-18/)
   * UTF-8 by Default
   * Simple Web Server
@@ -31,8 +36,8 @@ A project to explore more about the new features of Java 8, 9, ...
   * Unix-Domain Socket Channels
   * Warnings for Value-Based Classes
   * Foreign-Memory Access API (incubator)
-  * Vector API (Incubator)
-  * Foreign Linker API (Incubator)
+  * Vector API (incubator)
+  * Foreign Linker API (incubator)
   * Packaging Tool
 
 * [Java 15](java-15/) (Sep, 2020)

java-19/README.md

@@ -0,0 +1,42 @@
+# Java 18
+
+To run each example use: `java --enable-preview --source 18 <FileName.java>`
+
+## Features
+
+### Language
+
+* Pattern matching for `switch`
+  * Minor improvements from JDK 18:
+    * changed guarded pattern from `&&` to `when` keyword
+    * definition: guard is the boolean expression, guarded pattern is the case with guard
+      * guarded pattern: `case Hero h when h.getCity() == Cities.NEW_YORK`
+      * guard: `h.getCity() == Cities.NEW_YORK`
+* Virtual Threads (user-mode threads)
+  * `Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications`
+  * definitions:
+    * virtual thread is an instance of `java.lang.Thread` that is not tied to a particular OS thread, only consumes an OS thread only while it performs calculations on the CPU;
+    * platform thread is an instance of `java.lang.Thread` implemented a thin wrapper around an OS thread.
+  * blocking:
+    * `when code running in a virtual thread calls a blocking I/O operation in the java.* API, the runtime performs a non-blocking OS call and automatically suspends the virtual thread until it can be resumed later`;
+    * `virtual threads preserve the reliable thread-per-request style that is harmonious with the design of the Java Platform while utilizing the hardware optimally`
+  * virtual threads employ M:N scheduling, where a large number (M) of virtual threads is scheduled to run on a smaller number (N) of OS threads.
+  * `Virtual threads are not faster threads — they do not run code any faster than platform threads. They exist to provide scale (higher throughput), not speed (lower latency). There can be many more of them than platform threads, so they enable the higher concurrency needed for higher throughput according to Little's Law.`
+  * scenarios where it can significantly improve throughput when:
+    * number of concurrent tasks is high, and
+    * work is not CPU-bound.
+  * support thread-local variables and interruption
+  * more notes about Project Loom [here](../java-loom/)
+  * we can use `Executors.newVirtualThreadPerTaskExecutor` to create virtual threads
+
+## JEPs
+
+* [422](https://openjdk.java.net/jeps/422) - Linux/RISC-V Port
+* [424](https://openjdk.java.net/jeps/424) - Foreign Function & Memory API (Preview)
+* [425](https://openjdk.java.net/jeps/425) - Virtual Threads (Preview)
+* [426](https://openjdk.java.net/jeps/426) - Vector API (Fourth Incubator)
+* [427](https://openjdk.java.net/jeps/427) - Pattern Matching for switch (Third Preview)
+
+## Links
+
+* [JDK 19 Jeps](https://openjdk.java.net/projects/jdk/19/)

java-loom/README.md

@@ -31,7 +31,7 @@ About the API:
 
 > [...] we learned during that experiment — that we can keep parts of the Thread API and de-emphasize others — moved the needle in favor of keeping the existing API, and representing our user-mode threads with the Thread class. And here we are: virtual threads are just Threads, and any library that knows Thread already knows virtual threads.
 
-Abount concurrent access:
+About concurrent access:
 
 > [...] how do we limit concurrent access to some service? Instead of breaking the task down and running the service-call subtask in a separate, constrained pool, we just let the entire task run start-to-finish, in its own thread, and use a semaphore in the service-call code to limit concurrency — this is how it should be done.