JDK 14: Records, Text Blocks, and More

Today's Mark Reinhold post "JEPs proposed to target JDK 14: 305, 343, 359, 366, & 368" proposes targeting five more JEPs to JDK 14. Some highly anticipated features are among this group, although all but one are proposed to be in "preview" or "incubating":

• JEP 305: Pattern Matching for instanceof (Preview)
• JEP 343: Packaging Tool (Incubator)
• JEP 359: Records (Preview)
• JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
• JEP 368: Text Blocks (Second Preview)

The Java SE 13 Java Language Updates document describes preview features (JEP 12): "A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases."

JEP 11 ("Incubator Modules") describes "incubator modules" as "a means of putting non-final APIs and non-final tools in the hands of developers, while the APIs/tools progress towards either finalization or removal in a future release."

Four of the five JEPs proposed today for targeting JDK 14 are "preview" or "incubator" and so will be subject to potentially "not exist .... at all in future JDK releases" or potential "removal in a future release." However, the opportunity to take these features for a spin is welcome and there seems likely that these features will eventually become permanent even if they have some modifications. We could have these JEPs officially targeted for JDK 14 by Thanksgiving!

Additional Resources

• /r/java Discussion: Records Proposed to Target JDK14
• /r/java Discussion: JEP 305: Pattern Matching for 'instanceof' (Preview) is now proposed to target JDK 14

JDK 14: CMS GC is OBE

JDK 14 Early Access Build #23 (2019/11/13) is now available. One of the more noteworthy changes with this build is the removal of the Concurrent Mark Sweep garbage collector. JEP 291 ["Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector"] deprecated the Concurrent Mark Sweep (CMS) garbage collector back in 2017 with JDK 9 and JEP 363 ["Remove the Concurrent Mark Sweep (CMS) Garbage Collector"] has been targeted for JDK 14 to remove the CMS garbage collector altogether.

The next screen snapshot demonstrates that the CMS garbage collector was still available with JDK 14 Early Access Build #22.

With that JDK 14 Early Access Build #22, we see that specifying -XX:+UseConcMarkSweepGC is allowed with only a deprecation warning shown: "Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release."

The next screen snapshot demonstrates that CMS cannot be specified as a garbage collector as of JDK 14 Early Access Build #23:

When trying to run the Java application with -XX:+UseConcMarkSweepGC, the error message now shown states, "Ignoring option UseConcMarkSweepGC; support was removed in 14.0".

Although the removal of the CMS garbage collector was the biggest change I noticed in JDK 14 Early Access Build #23, there were a few other changes that I found to be somewhat interesting. These include:

• JDK-8226297: Dual-pivot quicksort improvements
  • Lengthy list of changes in the bug report.
• JDK-8232684: Make switch expressions final
  • Transitions switch expressions feature from "preview" to "final" (JEP 361).
• JDK-8233884: Avoid looking up standard charsets in security libraries
  • Reminder to take advantage of constants defined as public fields in the StandardCharsets class.

Six More JEPs Proposed for JDK 14

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

The goals of JEP 364 and JEP 365 are to "port the ZGC garbage collector" to macOS and Windows operating systems respectively.

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."

Conclusion

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.