wesleyegberto/java-new-features

1. Repository purpose and shape

- This is a feature showcase / learning monorepo for Java platform evolution, not a single application.

- The top level is organized by JDK release (java-7 through java-27) plus two dedicated project areas (projects/loom, projects/valhalla).

- The main architectural boundary is version isolation: each folder contains examples that are meant to compile and run against that specific Java release or preview/incubator feature set.

2. Primary execution model

- Most examples are small standalone programs or tests, each demonstrating one feature in isolation.

- There is very little cross-version or cross-folder coupling; each directory acts like its own mini-lab.

- This means the repo’s architecture is best drawn as a collection of independent demo modules, rather than a layered product with shared services.

3. Build and tooling boundaries

- Java 8 is the main Maven-based subproject (java-8/pom.xml, src/main/java/...).

- Later versions rely mostly on single-file/source-file examples and version-specific scripts such as build.sh.

- The repo intentionally spans multiple Java compiler/runtime modes: stable releases, preview features, incubators, and experimental APIs. That version-specific execution requirement is a core architectural concern.

4. Java 8 as the baseline feature suite

- java-8 is a conventional package hierarchy under com.github.wesleyegberto.

- It groups examples by language/API theme: lambdas, streams, collections, base64, datetime, validation, interfaces, method references, and reductions.

- This folder provides the “legacy baseline” against which later language and platform changes are contrasted.

5. Java 9: modularity and services

- java-9/modules is the first clearly modular subsystem, showing JPMS architecture.

- It contains separate modules for:

- services/provider

- services/consumer

- simple_deps split into math_api, math_lib, and calculator

- The architecture here demonstrates module boundaries, service provision/consumption, and dependency encapsulation, with shell scripts for building and launching module graphs.

6. Java 9+ platform/API feature labs

- java-9/others-features and java-10/java-11/java-12/... are mostly topic-focused demo suites rather than systems.

- Examples cover collections improvements, process API, reactive flow, HTTP client, streams, futures, and compact collections.

- The data flow is typically local and in-memory, with occasional interaction with the host process or external endpoints.

7. Networking and external interaction examples

- java-11 contains the clearest network-facing cluster: HTTP GET/POST, async/reactive HTTP client usage, and a reusable HttpBinRequestBuilder.

- java-18/SimpleWebServer.java and its static index.html/img assets form a tiny embedded web server + static content demo.

- These examples are isolated from the rest of the repo and usually interact with external services only for demonstration purposes, not as persistent dependencies.

8. Concurrency evolution track

- From java-12 onward, concurrency examples progress from CompletableFuture to virtual threads, structured concurrency, and scoped values in later versions.

- java-19, java-20, java-21, java-24, and java-25 contain the densest concurrency material.

- The architectural theme is the shift from thread-per-request / platform-thread stress tests to virtual-thread-based workloads and structured task grouping.

- Several java-19 stress programs and the JMX file suggest performance/load experimentation around thread scaling.

9. Language-model evolution track

- A large portion of the repo demonstrates changes to the Java type system and syntax:

- records

- sealed classes/interfaces

- pattern matching for instanceof and switch

- text blocks

- flexible constructors

- unnamed/implicitly declared classes and main methods

- string templates

- sequenced collections

- These samples are generally self-contained and show how newer syntax changes application structure, especially around data carriers and branching logic.

10. Native and low-level runtime integration

- java-22/person_validator.c alongside FFM examples shows Java-to-native interop using the Foreign Function & Memory API.

- java-24/ClassFileApi* demonstrates class-file reading/writing/transformation, which is a lower-level bytecode boundary distinct from normal source-level code.

- java-14/JFREventStreamTest.java and java-25/ProfilingTest.java point to runtime observability and profiling experiments.

11. Advanced platform/runtime features

- Several folders cover JVM/runtime changes that affect deployment or execution model:

- packaging tool / runtime image work

- Unix domain sockets

- value-based class warnings

- stable/lazy constants

- final-field mutation and primitive pattern previews

- These are not application subsystems; they are runtime behavior probes showing how the platform itself changes across versions.

12. Experimental project areas

- projects/loom is a focused set of Loom prototypes around virtual threads and thread counting/execution.

- projects/valhalla contains early experiments with primitive/value classes and records.

- These folders are conceptually separate from the versioned examples: they act as forward-looking R&D tracks for upcoming platform work.

13. Typical data flow pattern

- Most programs follow a simple flow: construct example inputs → invoke a Java API or language feature → print/assert results.

- A smaller subset crosses boundaries:

- HTTP client examples call external endpoints.

- FFM examples call native C code.

- JPMS service demos resolve provider/consumer relationships at runtime.

- Stress tests exercise the scheduler/runtime under load.

- There is no central database, queue, or shared domain model.

14. How to diagram this repo accurately

- Draw it as a versioned gallery of independent demo subsystems.

- Show a few key cross-cutting categories rather than one application stack:

- language features

- collections/streams/API updates

- modularity/services

- concurrency/runtime

- native interop

- observability/tooling

- Emphasize that JDK version is the primary organizing axis and that each folder is a self-contained boundary with its own compile/run assumptions.