How Java 14 Features Were Determined
How Java 14 Features Were Determined
Two years of on-time, six-month feature releases should allay concerns about Oracle's role as a steward of Java.
Join the DZone community and get the full member experience.Join For Free
Two years ago I wrote an article about the concerns with Java. These included: quality, release cadence and fatigue, taking security seriously, Oracle's role as a steward of Java, and progress relative to other languages. I began the conversation by asking Aurelio about these issues.
Aurelio was with Sun Microsystems prior to the Oracle acquisition. He explained the challenge of keeping the various members of the Java ecosystem happy. Developers are excited about features and functionality and would like to see a new release every week or two. System administrators want stability. They'd prefer updates or major releases every five years. They want bug and security vulnerability fixes that enable the platform to continue to run continuously. It's impossible to keep both happy.
According to Aurelio, "The six-month release cadence benefits both. With feature releases every six months, we're able to ensure bugs are worked out of features so they are not rushed due to a long-term release cycle. Tools used to lag a long time after releases. Today, users already have access to IntelliJ and Netbeans support for JDK 14."
The Java 14 release is the result of industry-wide development and collaboration involving open review, weekly builds, and extensive collaboration between Oracle engineers and members of the worldwide Java developer community via the OpenJDK Community and the Java Community Process.
The new features delivered in Java 14 include:
JEP 305: Pattern Matching for instanceof (Preview) – This preview feature enhances Java with pattern matching for the instanceof operator. This improves developer productivity by eliminating the need for common boiler plate code and allows more concise type-safe code.
JEP 343: Packaging Tool (Incubator) – Provides a way for developers to package Java applications for distribution in platform-specific formats. This helps developers with modern applications where constraints require runtimes and applications to be bundled in a single deliverable. This tools is introduced in an incubator module, which is a way of putting non-final APIs and non-final tools in the hands of developers to get their feedback while the APIs/tools progress towards either finalization or removal in a future release.
JEP 345: NUMA-Aware Memory Allocation for G1 – Improves the overall performance of the G1 garbage collector on non-uniform memory access (NUMA) systems.
JEP 349: JFR Event Streaming – Exposes JDK Flight Recorder (JFR) data for continuous monitoring. This will simplify access to JFR data for various tools and applications and spur further innovation.
JEP 352: – Adds a file mapping mode for the JDK when using non-volatile memory. The persistent nature of non-volatile memory changes various persistence and performance assumptions that are leveraged with this feature.
JEP 358: Helpful NullPointerExceptions – Improves the usability of
NullPointerExceptionsby describing precisely which variable was null and other helpful information. This will increase developer productivity and improve the quality of many development and debugging tools.
JEP 359: Records (Preview) – This preview feature provides a compact syntax for declaring classes that hold shallowly immutable data. This feature can greatly reduce boilerplate code in classes of this type, but the biggest benefit allowing the modeling of data as data. It should be easy, clear and concise to declare these shallowly-immutable nominal data aggregates.
JEP 361: Switch Expressions (Standard) – This was a preview feature in JDK 12 and JDK 13 and is now being added as a standard feature. It allows the switch to be used as either a statement or an expression. This feature simplifies everyday coding and prepared the way for the pattern matching (JEP 305) feature previewed in this release.
JEP 364: ZGC on macOS and JEP 365: ZGC on Windows – While most users that require ZGC also require the scalability of Linux-based environments, there are often needs for deployment and testing to support ZGC on macOS and Windows. There are also certain desktop applications targeting Windows and macOS which will benefit from ZGC.
368: Text Blocks (Second Preview) – After receiving end-user feedback when Text Blocks was first introduced as a preview feature as part of Java 13, enhancements have been added and Text Blocks is being offered as a preview feature again in Java 14 with the goal of becoming standard in a future JDK release. Text Blocks make it easy to express strings that span several lines of source code. It enhances the readability of strings in Java programs that denote code written in non-Java languages; it supports the migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, interpret the same escape sequences and be manipulated in the same ways as a string literal.
370: Foreign-Memory Access API (Incubator) – An API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap.
Aurelio took me through several of the JEP's (JDK Enhancement Proposals). JEP 305: Pattern matching for instanceof was created on May 30, 2017, and was discussed for a couple of years before being submitted as a JEP. This is true of most JEPs and you can follow the entire evolution of the JEP, what decisions were made, and why.
Aurelio urges Java developers to become involved in the process of contributing to and enhancing the JDK by going to https://openjdk.java.net/ to see what projects are currently being pursued, reviewing those, contributing suggestions, making bug fixes, or downloading a beta.
"It's very much a meritocracy, just show up with ideas, join the conversations. We're being completely transparent with the process."
Opinions expressed by DZone contributors are their own.