A recent Mark Reinhold message announces six new “JEPs proposed to target JDK 14”: JEP 345, JEP 361, JEP 363, JEP 364, JEP 365, and JEP 367. Assuming no objections are made by November 7, these JEPs will be targeted to JDK 14 along with previously targeted JEPs JEP 349 (“JFR Event Streaming”), JEP 352 (“Non-Volatile Mapped Byte Buffers”), and JEP 358 (“Helpful NullPointerExceptions“). This post summarizes each of these six JEPs proposed for targeting JDK 14.
JEP 345: NUMA-Aware Memory Allocation for G1
The succinct “Summary” of JEP 345 states, “Improve G1 performance on large machines by implementing NUMA-aware memory allocation.” Two important “non-goals” of this JEP indicate that the JEP is only intended to add NUMA (non-uniform memory access) support to the G1 garbage collector and only for Linux. However, the JEP also points out that “the parallel collector, enabled by by
-XX:+UseParallelGC, has been NUMA-aware for many years.”
JEP 361: Switch Expressions (Standard)
JEP 361 moves switch expressions from their JEP 325 “preview” status to “standard” status. Along the way, JEP 354 (targeted at JDK 13) made this change to the preview switch expressions feature: “To yield a value from a switch expression, the
break with value statement is dropped in favor of a
yield statement.” The “History” section of JEP 361 discusses switch expressions support in preview status in JDK 12 and JDK 13 and explains why it is proposed for standard status with JDK 14: “Feedback on JDK 13 suggests that this feature is now ready to be made final and permanent in JDK 14.”
JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
JEP 363‘s concise “Summary” states, “Remove the Concurrent Mark Sweep (CMS) garbage collector.” The Concurrent Mark Sweep (CMS) garbage collector was deprecated with JEP 291 (JDK 9) and this JEP aims to remove it altogether with JDK 14.
JEP 364: ZGC on macOS / JEP 365: ZGC on Windows
JEP 364’s “Motivation” section states, “While we expect users that require the scalability of ZGC to use Linux-based environments, it is not uncommon that developers use Macs for local development and testing, before deploying applications.” Although JEP 365 lacks an explicit “Motivation” section, its motivation is probably similar to that for JEP 364.
JEP 365’s “Non-Goals” section states, “It is not a goal to support Windows 10 and Windows Server older than version 1803, since older versions lack the required API for placeholder memory reservations.”
JEP 367: Remove the Pack200 Tools and API
The “Summary” section of JEP 367 begins with this statement, “Remove the pack200 and unpack200 tools, and the Pack200 API in the
java.util.jar package.” This removal of these tools and APIs was advertised in Java SE 11 via JEP 336 when they were deprecated.
The “Motivation” sections of both the deprecation JEP 336 and the removal JEP 367 list three reasons for deprecating and removing Pack200 and conclude with this statement, “Overall, the cost of maintaining Pack200 is significant, and outweighs the benefit of including it in Java SE and the JDK.”
The “Risks and Assumptions” section of JEP 336 includes this statement, “We assume that developers who use
pack200 to shrink application JARs can switch to either the
jlink tool or the
jpackage tool to create application-specific runtimes with an optimized form factor.” There is discussion regarding the suitability of jlink and jpackage on the r/java sub-reddit.
Java SE Specification Impacts
Iris Clark has posted that two of these JEPs have Java SE scope. She writes that JEP 361 (switch expressions standard) and JEP 367 (removing Pack200) are “of scope ‘SE’ [and] have been Proposed to Target for Java SE 14.”
If all six of these JEPs proposed for JDK 14 get targeted for JDK 14, there will be nine JEPs associated with JDK 14. Two that I’m particularly looking forward to are the standardizing the switch expressions feature with JEP 361 and better NPE messages with JEP 358.