English: Systematic Best Practices for Java's New Features

doc/JavasNewFeaturesBestPractices_en.md

@@ -0,0 +1,124 @@
+# Systematic Best Practices for Java's New Features: Java has abandoned OOP in favor of my theory!!
+
+Copyright © 2024.04.15 Lin Pengcheng. All rights reserved. 
+
+Starting with Java 8, Java started to change its slow 
+and clunky image, trying to add new features and 
+improve performance. However, since Java's main 
+application area is enterprise applications, 
+the strategy of updating the programming language 
+is more conservative, and most of them are still 
+sticking to Java 8, and not many enterprises 
+or individuals are applying the new features of Java. 
+There are only brief introductions to the stand-alone 
+use of individual new features, not articles on 
+best practice guidelines for the systematic use of 
+multiple new features, and people don't realize that 
+Java has abandoned OOP in favor of my theory, 
+[**"The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow)!
+
+- Workshop: Stream (JDK 8-9), Stream Gatherers (JDK 22)
+
+  Stream is an object-style pipeline operation used to
+  construct a pipeline of production data 
+  within the workshop.
+
+- Warehouse: Records (JDK 14 to 16)
+
+  Record is an immutable datatype that is used as a data carrier, 
+  primarily in scenarios where data is stored,
+  preserved, and there is no additional custom behavior. 
+  It is very suitable for use as a "repository", of course, 
+  if there are special needs, other Java classes are more
+  suitable, it can also be applied, my theory has a strong
+  compatibility. See also: [**"The unification with FP and OOP"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow#The-unification-with-object-oriented)
+
+    - Class: In my theory classes are mainly used as 
+      namespaces to organize code, or compatible with 
+      OOP to use traditional Java code.
+
+    - Object: Objects are not needed in my theory, 
+      which is used for compatibility with OOP 
+      in order to use traditional Java code.
+
+- Scheduler: Virtual Threads (JDK 19-21), Structured Concurrency (JDK 19-22)
+
+  - Structured Concurrency
+
+    Used to construct the scheduler algorithm: 
+    Dynamic Tree Gantt Chart (Operations Research).
+
+  - Virtual Threads
+
+    Used to run tasks after assigning them to workshops.
+
+- Other New Features
+
+  - JEP 467: Markdown Document Annotation
+
+    This feature uses my original method from 2019-02-17,
+    [**"Markdown Literary Programming that don't break the syntax of any programming language"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/markdown_literary_programming.md).
+    My approach is simpler, flexible, visual, extensible, 
+    and applicable to all programming languages and 
+    markup languages.It takes source code from the text age to the web age, 
+    and improves the functionality and experience dramatically.
+
+    Demo: [LivePreview in Notepad++](https://github.com/linpengcheng/ClojureBoxNpp)
+
+  - Native Compilation (GraalVM), Native Code Interaction
+
+    Similar to what I said in 
+    [**"The unification with Programming Language Platform"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow#The-unification-with-Programming-Language-Platform), 
+    except that I advocate using Lisp to represent 
+    the intermediate language, which is simpler, clearer, 
+    more convenient, and easier to implement and extend;
+    GraalVM uses JVM bytecode as intermediate language.
+
+  - Syntax enhancements, tool enhancements
+
+    These have nothing to do with programming paradigms 
+    and will not be discussed.    
+
+In summary, the new features of Java indicate that Java 
+has abandoned OOP in favor of my theory, 
+[**"The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow)! 
+Combined with Java's strong development of native 
+compilation and native code interaction, it shows that 
+Java's two core concepts of OOP and virtual machines 
+have been abandoned.
+
+Why did Java abandon OOP in favor of my theory? 
+The reason is as follows:
+
+- Java's main application area is enterprise application
+  software, from the reference model, my Warehouse/Workshop
+  Model is a natural and direct counterpart to the
+  architecture of enterprise application software, 
+  which is simple, clear, and much superior to the 
+  current mainstream OOP, FP, and command programming.
+
+- In my Chinese article [**"Traditional IT theory (OO, FP and hardware architecture, etc.) VS. Warehouse/Workshop Model"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow#Traditional-OO-and-FP-architecture-VS-Warehouse-Workshop-Model), 
+  I pointed out that my Warehouse/Workshop Model is based on
+  mathematical models, which is a downgrade from the
+  pseudo-science of OOP, FP, and imperative programming.
+
+- My Warehouse/Workshop Model is data-centered, which is
+  consistent with database thinking, so database vendors 
+  are natural allies of my theory, and Oracle, the owner 
+  of Java, is the largest database vendor, so it's a 
+  natural choice for Java to turn to my theory.
+
+- In my Chinese article [**"My theory has an estimated 100,000 high level followers around the world (Attachment: Most authoritative peer review)"**](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/estimated_100k_high_level_followers.md), 
+  I pointed out that my Warehouse/Workshop Model has 
+  already achieved absolute victory at the lowest level 
+  of CPU/SoC chips and computer hardware architectures, 
+  and that in the IT field, the lowest level of technology
+  determines the upper level of technology, and thus my 
+  theory has achieved absolute victory at all levels of 
+  the IT field, such as OS, DB, programming languages, 
+  and application development. It's just a matter of time,
+  this is the inevitable law, the Java language change 
+  is just a beginning.
+
+Whether Java had the idea written in this article before or not, 
+from now on, Java must have the idea and work hard to develop for it! :-)