New features comes with Java 13
JEP 353 — Reimplement the Legacy Socket API
JEP 353 covers the new implementation of the Socket API. To be more precise, an additional, more modern implementation of the Socket API (which was introduced in Java 1), has been added to the core libraries. The old Socket API is available via a JDK system property and the PlainSocketImpl class (but not for long).
The first, and in my opinion most important feature of the new implementation, is that sockets are polled in non-blocking mode and are accessed via an operation limited by a timeout by default. Why is this important? Effectively, it means you can perform operations on a Socket object without having to wait for the Socket to respond before making an additional operation on said Socket. Consider an application that relies on external APIs for a subset of its functionality. If you start the application with a blocking Socket, you will have to wait for your Socket operations to complete before continuing your application. But if you were to initiate a connection to an API service using a non-blocking socket and store the result in a Future<> object, you can continue your application’s initialization steps without waiting for a response. This is particularly convenient when decoupling your application’s initialization and third-party dependencies.
JEP 350 — Dynamic CDS Archives
This particular enhancement modifies the JRE more than anything; most Java developers will not notice this enhancement in their day to day development. The origins of this JEP start in Java 10, with JEP 310. Class-Data Sharing has been around since JDK 5, but it was codified as “Application Class-Data Sharing” for Java 10. Effectively what happens is meta-data across a developer-specified list of classes are shared in an archive file. This archive file is then loaded and referenced by the JVM. If this archive file is built from 100 class files, you save the JVM a lot of time and energy by referencing just the one file. This reduces memory footprint and application load times.
So what feature has been added to CDS in Java 13? Java 13 introduces dynamic archiving. Before Java 13, making a CDS archive required the completion of several steps. As outlined in JEP 350, the steps are:
- Do one or more trial runs to create a class list
- Dump an archive using the created class list
- Run with the archive
These steps are all achievable via java CLI options. Depending on the size of the application, these commands may be difficult to run. This is where Dynamic CDS comes in. This enhancement performs step 1 at the end of your application’s execution, let’s say in your QA build process. From here its just a matter of building your archive file and dropping it into a CI/CD pipeline for deployment. The manual steps required to build the class list required to create the archive is completely gone with Dynamic CDS Archives.
JEP 351 — ZGC: Uncommit Unused Memory
ZGC was a new garbage collector introduced to Java in Java 11. It was designed to work on environments with massive compute capacity and memory requirements, significantly greater than desktop computing. While other garbage collectors have their perks, ZGC is the best choice for applications with significant memory and compute requirements.
ZGC is not without limits though. Before Java 13, ZGC never returned memory to the OS without a restart. This feature is common to most garbage collectors; most traditional GCs return memory to the OS by default as they were designed to run on commodity or even embedded hardware with severely restricted memory and compute requirements. Not being able to return memory to the OS would have significant repercussions on application performance. If we consider the origins of ZGC though, it is easy to see why this feature was not built-in. If you have thousands of gigabytes of RAM installed on your host machine, you likely do not need to return it to the OS. Regardless, this feature was added to ZGC in Java 13, making it an option for applications that do not always run on specialized, enterprise-level machines.
Future Directions
Java 13 is the next chapter in the quest to make Java a viable functional language. Since Oracle has taken over the development of Java, it has gradually evolved into a modern language, capable of keeping up with the hottest trends in application development. Since Java 8, the language has steadily evolved into a discrete, easily readable, easily extensible language capable of keeping up with other languages like Python, Scala, and Kotlin.
At the time of this post’s writing, Java 14 is scheduled to be released in March of 2020. JEP 352 is the only addition scheduled for Java 14, but that last will likely grow to include several more JEPs from the index before the end of 2019.
Related blog:
