| created on | July 16, 2022 |
general availability on 2018-09-25
| JEP | state | summary /remark |
|---|---|---|
| JEP 181: Nest-Based Access Control | standard | introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other’s private members without the need for compilers to insert accessibility-broadening bridge methods. |
| JEP 309: Dynamic Class-File Constants | standard | extend the Java class-file format to support a new constant-pool form, CONSTANT_Dynamic. |
| JEP 318: Epsilon | experimental | a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down. |
| JEP 321: HTTP Client | standard | standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10. |
| JEP 323: Local-Variable Syntax for Lambda Parameters | standard | I prefer the implicitly typed lambda expressions as in Java SE 8 :) |
| JEP 324: Key Agreement with Curve25519 and Curve448 | standard | more efficient and secure than the elliptic curve Diffie-Hellman (ECDH) scheme |
| JEP 327: Unicode 10 | standard | Java SE 10 implements Unicode 8.0 |
| JEP 328: Flight Recorder | standard | records events originating from applications, the JVM and the OS with an performance overhead of under 1%. intended for monitoring, profiling and troubleshooting of apps in production |
| JEP 329: ChaCha20 and Poly1305 Cryptographic | standard | ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher. |
| JEP 330: Launch Single-File Source-Code Programs | standard | you can now launch single file Java apps with a shebang |
| JEP 331: Low-Overhead Heap Profiling | standard | low-overhead way of sampling Java heap allocations, accessible via JVMTI. |
| JEP 332: Transport Layer Security (TLS) 1.3 | standard | implement version 1.3 of the Transport Layer Security (TLS) Protocol RFC 8446. |
| JEP 333: ZGC, A Scalable Low-Latency Garbage Collector (Experimental) | experimental | the Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector. |
| JEP | summary /remark |
|---|---|
| JEP 315: Improve Aarch64 Intrinsics | specialized CPU architecture-specific code patterns improve the performance of user applications and benchmarks. |
| JEP | summary /remark |
|---|---|
| JEP 335: Deprecate the Nashorn JavaScript Engine | the nashorn engine is a complete implementation of the ECMAScript-262 5.1 standard. With the rapid pace at which ECMAScript language evolves, there’s not enough dev power to maintain Nashorn. Might get resurrected if there are enough devs to maintain a complete implementation of the ECMAScript standard. |
| JEP 336: Deprecate the Pack200 Tools and API | Pack200 is a compression scheme for JAR files, introduced in Java SE 5.0. Its file format is tightly coupled to the class file format and the JAR file format. Pack200 has been used especially to compress the JDK up to version 8 and applets. Applets are gone and Java 9 and later versions do not rely on Pack200. |
| JEP | summary /remark |
|---|---|
| JEP 320: Remove the Java EE and CORBA Modules | From the JEP: “There is no significant interest in developing modern applications with CORBA in Java.”. Yep, CORBA sucked from the time of its inception. |
A no-op GC is useful in the following scenarios:
" For ultra-latency-sensitive applications, where developers are conscious about memory allocations and know the application memory footprint exactly, or even have (almost) completely garbage-free applications, accepting the GC cycle might be a design issue. There are also cases when restarting the JVM -- letting load balancers figure out failover -- is sometimes a better recovery strategy than accepting a GC cycle. "
JEP 318: Epsilon: A No-Op Garbage Collector (Experimental)
The Epsilon GC can be enabled with .
The HTTP Client replaces the HttpURLConnection API, which is known for a number of problems:
Among the features of the new HTTP Client are:
goals of ZGC:
Initially supported platform: Linux/x64
The initial experimental version of ZGC has the following limitations:
Experimental features in the JVM are disabled by default by the build system. ZGC can be enabled at compile-time using the configure option (ZGC will be present in all Linux/x64 JDK builds produced by Oracle).
To enable/use ZGC for runtime, use the JVM options .
OpenJDK JDK 11 Feature List and Schedule
JEP 318: Epsilon
JEP 321: HTTP Client
JEP 333: ZGC, A Scalable Low-Latency Garbage Collector (Experimental)