JDK 14: The new features in Java 14

Java Development Kit (JDK) 14 has moved to a second rampdown phase, with the overall feature set now frozen. The planned upgrade to standard Java will feature new capabilities such as JDK Flight Recorder event streaming, pattern matching, and switch expressions. 

[ Also on InfoWorld: 10 software development cults to join | Keep up with hot topics in software development with InfoWorld’s App Dev Report newsletter ]

JDK 14 is scheduled for a production release on March 17, 2020, following the six-month release cadence set for Java. The features targeted to JDK 14 include:

• JFR Event Streaming provides an API for the continuous consumption of JFR data from both in-process and out-of-process applications. JFR is a tool for collecting profiling and diagnostic data about a running Java application. The event streaming proposal records the same set of events as for the non-streaming case, with overhead of less than one percent if possible. Event streaming must co-exist with non-streaming recordings, both disk-based and memory-based. Motivating this proposal is a situation in which the HotSpot VM emits more than 500 data points using JFR, most of them available only by parsing log files. Currently, a user must start a recording, stop it, dump the contents to disk, and then parse the recording file. This works well for application profiling, but not for monitoring purposes. An example of monitoring usage is a dashboard that displays dynamic updates to data. There is overhead with creating a recording, such as copying data from the disk repository to a separate recording file. If there were a way to read data being recorded from the disk repository without creating a new recording file, much of the overhead could be avoided.
• The planned improvement to NullPointerExceptions pertains to improving the usability of the exceptions generated by the JVM by describing exactly which variable was null. Authors of the proposal are looking to provide helpful information to developers and support staff about the premature termination of a program and improve program understanding by more clearly associating a dynamic exception with static program code. One goal is to reduce confusion and concern developers have about NullPointerExceptions.
• Non-volatile mapped byte buffers would add new JDK-specific file mapping modes that allow the FileChannel API to be used to create MappedByteBuffer instances that refer to non-volatile memory (NVM). NVM enables programmers to build and update program state across program runs without incurring the significant copying or translation costs that input and output operations usually require. This is particularly significant for transactional programs. Thus the chief goal of this JDK Enhancement Proposal is to ensure that clients can access and update NVM from a Java program coherently and efficiently. A secondary goal is to implement this commit behavior using a restricted, JDK-internal API defined in class Unsafe, so it can be re-used by classes other than MappedByteBuffer that may need to commit to NVM. Another goal is to allow buffers mapped over NVM to be tracked by existing APIs for monitoring and management. Target OS/CPU platforms include Linux/x64 and Linux/AArch64.
• Switch expressions simplify coding by extending switch so that it can be used as either a statement or an expression. Switch expressions are expected to be a permanent feature in JDK 14, after being previewed in both JDK 12 and JDK 13. Switch expressions also prepare for the use of pattern matching in switch. Pattern matching allows developers to conditionally extract components from objects more concisely and safely. 
• NUMA-aware memory allocation for the G1 garbage collector, intended to improve G1 performance on large machines. 
• Removal of the Concurrent Mark Sweep (CMS) garbage collector, which previously was deprecated and slated for removal. Successors to CMS have arisen including ZGC and Shenandoah. 
• Porting of ZGC to MacOS. It has been supported only on Linux thus far.
• Removal of the pack200 and unpack200 tools and the Pack200 API in the java.util.jar package. These all were deprecated in Java SE 11 with the intent to remove them in the future. Pack200 is a compression scheme for JAR files.
• Records, which would provide a compact syntax for declaring classes that are transparent holders for shallowly immutable data. The proposal states it should be easy and concise to declare shallowly immutable, well-behaved, nominal data aggregates.
• A packaging tool, in an incubator phase of development, for packaging self-contained Java applications. The tool would be based on the JavaFX javapackager. Such a tool had been included in Java but was cut from JDK 11 as part of the removal of JavaFX.
• Enhance the language with pattern matching for the instanceof operator. This would be a preview feature in JDK 14. Pattern matching allows common logic in a program, principally the conditional extraction of components from objects, to be more concisely and safely expressed.
• A second preview of text blocks, a multi-line string literal that avoids the need for most escape sequences and automatically formats the string in a predictable way. Text blocks would give the developer control over the format when desired, simplify the writing of Java programs, and enhance the readability of strings. Text blocks was previewed in JDK 13; the JDK 14 iteration would add escape sequences for managing explicit white spaces and newline control.
• Deprecating the combination of the Parallel Scavenge and Serial Old garbage collection algorithms. Java maintainers believe this combination is used very little but requires a lot of maintenance.
• Porting of the ZGC (Z Garbage Collector) to Windows. This feature has once again moved to the officially targeted list, after having been reverted back to the proposed-for-targeting list.
• Foreign-memory access API, with the introduction of an API for Java programs to safely and efficiently access foreign memory outside of the Java heap. This API should serve as an alternative to the main avenues by which Java programs access memory, including nio.ByteBuffer and sun.misc.Unsafe. The new API should be able to operate on various kinds of memory including native, persistent memory, and managed heap. It should not be possible for the API to undermine the safety of the JVM. Memory deallocation should be explicit in the source code. The API is expected to aid in the development of the native interoperation support that is the goal of Project Panama.
• Deprecation of the Solaris/Sparc, Solaris/x64, and Linux/Sparc ports, with the intent to remove them in a future release. Dropping support for these ports will enable OpenJDK contributors to accelerate the development of new features. Although Solaris and Sparc were linchpin technologies at Sun Microsystems, the original creator of Java, they have been superseded in the technology space in recent years by the Linux OS and Intel processors.

[ Also on InfoWorld: The new features in Java 13 ]