Java Development Kit 12, the next version of Java SE, has reached the point where its major feature set is frozen. But one existing proposal in JDK 12, for raw string literals, could be removed from the release this week.
The planned Java upgrade is due for production release on March 19, 2019, with a release candidate expected a month earlier. Beta builds of JDK 12 are available from Oracle for Linux, Windows, and MacOS.
[ All the new features that matter in Java JDK 11. • 15 Java frameworks that give developers a boost. | Keep up with hot topics in programming with InfoWorld’s App Dev Report newsletter. ]
Where to download the beta JDK 12 builds
You can download the beta JDK 12 builds from the Java.net website.
The open source builds, which are produced to gather feedback, might have functionality that does not make it into the production release, which is due in March 19, 2019. They also might be missing security vulnerability fixes and are not supported by Oracle.
The planned new features in Java 12
Shenandoah garbage collector
This proposal calls for adding Shenandoah, an experimental garbage-collection algorithm, to reduce garbage-collection pause times by performing evacuation work concurrently with running of Java threads. Shenandoah provides an appropriate algorithm for applications that value responsiveness and predictable short pauses. The intent is not to fix all JVM pause issues, however.
Red Hat currently supports Shenandoah on the Aarch64 and AMD64 architectures.
Abortable mixed collections for the G1 garbage collector
This proposal would make G1 mixed collections abortable if they might exceed the pause target. A goal of G1 is to meet a user-supplied pause time target for its collection pauses.
Currently, an advanced analysis engine selects the amount of work to be done during a collection. The result is a set of regions known as the collection set. Once the set has been determined and collection started, G1 must collect all live objects in the regions of the collections in all regions without stopping. But this can lead to G1 exceeding the pause-time goal if an application’s heuristics choose a collection set that is too large.
A mechanism is needed to detect when heuristics repeatedly select an incorrect amount of work for collections and, if this happens, have G1 perform collection work incrementally in steps, where the collection can be aborted after each step. The proposed mechanism would enable G1 to meet the pause time goal more often.
Prompt return of unused committed memory
G1, under this proposal, would be enhanced to automatically return Java heap memory to the operating system when idle. This memory would be released in a reasonable period of time when there is very low application activity.
G1 does not currently do this. Memory is only returned from the heap at either a full garbage-collection or during a concurrent cycle. With G1 trying to avoid full garbage collection, only triggering a concurrent cycle based on heap occupancy and allocation activity, it will not return heap memory in many cases unless forced to do so externally. This behavior is disadvantageous in container environments where resources are paid by use. Even when the VM uses only a fraction of its assigned memory due to inactivity, G1 retains the full heap. So, customers pay for all resources all the time, and cloud providers cannot fully use their hardware.
It would be beneficial if the VM could detect phases of heap underutilization and automatically reduce its heap usage during that time. The proposal attempts to do so.
JVM constants API
This API would model nominal descriptions of key-class file and runtime artifacts, particularly constants loadable from the constant pool. The proposal defines a family of value-based symbolic reference types in a new package, java.lang.invoke.constant, to describe each kind of loadable constant.
Constant pools exist in every Java class, storing operands and bytecode instructions in the class. Entries in the constant pool describe either runtime artifacts such as classes and methods or simple values such as strings and integers. These entries are known as loadable constants.
Programs that manipulate class files must model bytecode instructions and in turn loadable constants. But using standard Java types to model loadable constants is inadequate. This may be acceptable for a loadable constant that describes a string, but it is problematic for a loadable constant that describes a class, because producing a “live” Class object relies on the correctness and consistency of class loading. Class loading, however, has many environmental dependencies and failure modes.
So, programs that deal with loadable constants would be simpler if they could manipulate classes and methods and less-known artifacts such as method handles and dynamically computed constants in a nominal, symbolic form. Libraries and tools would benefit from a single, standard way to describe loadable constants, which is the goal here.
Improved startup, CDS, and garbage collection
Plans call for enhancing the JDK build process to generate a default class data-sharing (CDS) archive, using the default class list, on 64-bit platforms. The goal is to include out-of-the-box startup time and eliminate the need to run -Xshare:dump to benefit from the CDS. Plans call for modifying the JDK build to run java-xshare:dump after linking the image.
Additional command-line options may be included to fine-tune garbage-collection heap times to improve memory layout for common cases. Users with more advanced requirements, such as custom class lists that include application classes and different garbage-collection configurations, still will be able to create a custom CDS archive.
Reduced number of ARM ports
Java 12 would have just one port instead of two for ARM processors. The plan is to remove all sources related to the arm64 port while retaining the 32-bit ARM and 64-bit aarch64. Removal of this port would let contributors focus efforts on a single 64-bit ARM implementation and eliminate duplicate work that would result from maintaining two ports. Currently, two 64-bit ARM ports are in the JDK.
Switch expressions
The beta switch expressions capability would simplify coding by extending the switch statement so it can be used as either a statement or an expression. This would enable both forms to use either “traditional” or “ simplified” scoping and control flow behavior. These changes would result in simplified “everyday” coding and prepare the way for use of pattern matching in switch.
As Java builders move to support pattern matching, existing irregularities of the existing switch statement become impediments. These include the default control flow behavior of switch blocks; default scoping of switch blocks, in which the block is treated as one single scope; and switch working only as a statement. The current design of Java’s switchstatement follows closely languages such as C++ and, by default, supports fallthrough semantics. This control flow has been useful for writing low-level code. But as switch is used in higher-level contexts, its error-prone nature begins to outweigh flexibility.
Raw string literals
The beta raw string literals would span multiple lines of source code while not interpreting escape sequences, such as \n, or Unicode escapes, of the form /uXXX. Java’s builders have multiple goals for this capability, including:
- Making it easier to express a sequence of characters in a readable form, without Java Simplification in supplying strings targeted for grammars other than Java.
- Supplying strings that span several lines of source code without having special indicators for new lines.
- The ability to express the same strings as traditional string literals, except for platform-specific line terminators.
- Library support to replicate the current javacstring-literal interpretation of escapes and manage left-margin trimming.
Java 12's developers say real-world Java code needs a mechanism for capturing literal strings as is, without special handling of Unicode escaping, backslash, or new lines. A raw string literal sets aside both Java escapes and Java line terminator specifications, providing character sequences that in many circumstances are more readable and maintainable than the existing string literal.
Java has remained one of the few languages without language-level support for raw strings. The proposal would not introduce any new string operators. Also, raw string literals also do not directly support string interpolation. There would be no change in the interpolation of traditional strings.
Basic benchmark suite
Java Development Kit (JDK) 12 is expected to include a basic suite of benchmarks that would be added to the platform’s source code. The goal is to make it easier for developers to run existing benchmarks or build new ones.
The microbenchmarks suite proposal, created in July 2014 and updated in early November 2018, is underpinned by the Java Microbenchmark Harness (JMH), for building benchmarks written in Java and other JVM languages. The suite would be colocated with JDK source code in a single directory, with developers able to easily add new benchmarks.
It is not a goal to provide benchmarks for new JDK features or create a complete set of benchmarks covering everything in the JDK.
There are risks to the plan, such as significant increase in build time, potential test instability in new benchmarks, and increasing the source-code repository size. But the benchmarking suite is not required for regular JDK builds and will be a separate build target. To address potential test instability, thorough testing will be required for new benchmarks.
The proposal calls for creation of a new page on wiki.openjdk.java.net to explain how to develop benchmarks and describe requirements. These requirements will mandate adherence to coding standards, reproducible performance, and documentation.