JDK 13: new features coming

Official development targets for Java 13, due in late 2019, start with improvements to garbage collection and application class-data sharing

Pro

(Image: Stockfresh)

21 May 2019

The first official planned features have been logged for Java Development Kit (JDK) 13, the next version of standard Java. Although several features had been proposed for the upgrade either verbally or in JDK Enhancement Proposals (JEPs) in recent months, these proposals — including a reimplementation of the legacy socket API, garbage collector enhancements, and application class-data sharing — had not been made official targets until now.

JDK 13 is due September 17, 2019, following rampdown and release candidate stages slated to begin in June and August, respectively. Here are the features now officially proposed for JDK 13:

Reimplementing the legacy socket API, which would involve replacing the underlying implementation used by the net.Socket and java.net.ServerSocket APIs with a simpler, more modern implementation that is easy to debug and maintain. The new implementation is intended to be easy to adapt to work with user-mode threads, also known as fibers, which are being explored in Project Loom. The aforementioned legacy APIs date back to JDK 1.0 and comprise a mix of legacy C and Java code described as painful to debug and maintain. The legacy implementation also has other issues: a native data structure to support asynchronous close, causing reliability and porting issues, and concurrency issues requiring an overhaul.

Enhancing the ZGC (Z Garbage Collector) to return unused memory to the operating system, a proposal cited as integrated into JDK 13. ZGC, which is billed as a scalable, low-latency collector, currently does not return unused memory back to the OS even if the memory has not been used in a long time. This behavior is not optimal for some applications and environments, especially those where memory footprint is a concern, such as containers or environments where an application might be idle for a long time and is sharing or competing for resources with other applications.

Extending application class-data sharing (AppCDS) to enable dynamic archiving of classes at the end of application execution. Archived classes would include all loaded application and library classes not present in the default, base-layer CDS archive. This proposal, which is in the targeted stage, is intended to improve the usability of AppCDS and eliminate the need for users to do trial runs to create a class list for each application.

Also expected in JDK 13
Three capabilities deemed worthy for JDK 13 inclusion have not yet been added to the official list. These include:

Development of a
tool for packaging self-contained Java applications, called jpackage. The tool would be based on the JavaFX javapackager tool that supports native packaging formats
to give the user a natural installation experience. It allows launch-time
parameters to be specified at packaging time. The tool can be invoked directly
from the command line or programmatically via the ToolProvider. Many applications need to be installed on a
native platform in a “first-class” way rather than being placed on the class
path or module path. A packaging tool also can fill gaps left by technologies
such as Java Web Start, which was removed from Oracle’s JDK 11. The javapackager tool was deleted from JDK 11 as part
of the removal of JavaFX.
Raw string literals,
which can span multiple lines of source code and do not interpret escape
sequences. This capability had been cut from JDK 12,
which arrived in March 2019. The plan is to offer raw string literals only as
an opt-in beta in JDK 13. Its goal is to make development easier n Java by, for
example, letting developers express sequences of characters in a readable form
free of Java indicators, or supply strings targeted for grammars other than
Java. Following the expected test run in JDK 13, raw string literals could be
made production-quality in the subsequent JDK 14 release.
A production version
of switch expressions, for which JDK will offer a beta implementation. The switch statement will be extended for use as either
a statement or an expression, so both could use either a “traditional” or
“simplified” scoping and control flow behaviour.