|JDK 12 Feature Set Frozen|
|Written by Kay Ewbank|
|Monday, 07 January 2019|
The feature set for the next version of Java SE, JDK 12, is now known as the development team has frozen the feature set for the new version. While many of the proposed improvements have made the cut, support for raw string literals is no longer included.
The changes that have made it include a new experimental garbage collector called Shenandoah, a better switch statement, and a variety of improvements to the G1 garbage collector.
Two main areas of the G1 garbage collector having received attention. The collector has been changed so that all pauses in G1 are abortable. One of the goals of G1 is to meet a user supplied pause time target for its collection pauses. However, until now, if too large a collection set was put in motion, G1 would wait for longer than the desired pause time goal. This can now be detected and aborted. The second change is an enhancement to automatically return Java heap memory to the operating system when idle.
The Shenandoah garbage collector has also been included in an experimental version. This is designed to reduces garbage collection pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.
A preview of an extended switch statement is the other main addition to JDK 12. The intention is to extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a "traditional" or "simplified" scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching in switch.
The feature that hasn't made it is support for raw string literals. These were meant to provide a literal that could span multiple lines of source code and to not interpret escape sequences, such as \n, or Unicode escapes of the form \uXXXX.
The decision not to include the feature as it stands is down to the fact it's not performing well enough, according to an email from Brian Goetz, Java Language Architect at Oracle. He said:
"The Preview Feature mechanism is intended for features for which there is a high confidence that the feature is "done", and the likelihood that significant changes would be made before making the feature permanent is low. At this time, and after extensive consideration, Jim and I no longer believe this to be the case, and we think letting it preview in its current state would be to the detriment of the language. We're of course disappointed that this means it will take slightly longer for this feature to make it into the language, but we think that's the best choice."
The email goes on to explain that by withdrawing, the developers can continue to refine the design, explore more options, and aim for a preview that actually meets the requirements of the Preview Feature process.
or email your comment to: firstname.lastname@example.org