Top 5 Java 13 Features You Can Learn Today
Text Block, Switch Expression, Socket API and all you need to know on the latest JDK release is there.
As expected, the new version of Java has just been released 6 months after the previous one. This new tightened calendar decided by Oracle since Java 9 allows us to have two so-called major versions of Java available per year. However, these versions have only the name of major as we will see in this article by detailing the new features brought by Java 13.
The new roadmap decided by Oracle for Java since the release of Java 9 in September 2017 allows us to have two so-called major versions of Java each year. Thus, Java 12 was released in March 2019 and Java 13 is also on time since this version was released in September 2019 as planned.
A Long-Term Support That Makes The Difference
Now, to differentiate between major and minor versions of Java, it is more important to look at the long-term support date announced by Oracle. Thus, the long-term support date of Java 8 runs until March 2022 and can be extended to March 2025 for a fee.
For Java 10, this date corresponded to September 2018 without any possibility of extension. On the Java 11 side, we have a long-term support date extending to September 2023 with a possible extension to September 2026.
The version 13 of the JDK that has just been released will benefit from long-term support not exceeding March 2020 and therefore, the release of the next version of the JDK.
All this allows us to deduce that the latest major versions of the JDK are 8 and 11.
On the enterprises’ side, this new operating model has been well integrated. Thus, most of them have remained in Java 8 while the most advanced have switched to Java 11 and are waiting for the next version with long-term support worthy of the name to eventually migrate.
All this is obviously not without causing compatibility problems with open-source code libraries that cannot keep up with the pace imposed by Oracle.
That being said, I suggest you discover the new features brought by Java 13 in order to get a better idea of what this new version will bring you.
1. Introduction Of Text Blocks
The major new feature of Java 13 for developers is the introduction of Text Blocks. Again, the architects in charge of Java evolutions have decided to proceed with caution since Text Blocks are only available as an experimental feature in Java 13.
Nothing extraordinary though, since Text Blocks are simply a new type of String Literal that allows you to write strings on several lines. In order to simplify their use, it was decided that a Text Block would start with a new specific delimiter and a line break. This allows simple quotes to be used within a Text Block without having to escape them.
We can, therefore, declare our first Text Block as such:
This use of the Text Block is equivalent to the construction of the following String object:
Text Blocks are also powerful because they retain the indentation defined by the user at the time of declaration in the source code. Only the indentation made before the first letter is deleted because it is considered accidental.
It should also be noted that a line break defined before the specific end delimiter will be considered as voluntary and will, therefore, be well taken into account in the String thus built at runtime.
Finally, this introduction of Text Blocks has led to the addition of three new utility methods within the String class that it is good to know because they could be useful to you one day or another:
- String::stripIndent() used to remove white space accidentally added to the content of a Text Block
- String::translateEscapes() used to translate escape sequences
- String::formatted(Object... args) which should simplify value substitution in a Text Block
2. Changes On Switch Expressions
Switch Expressions have been introduced as an experimental feature in Java 12. A modification has been proposed for Java 13 and for the moment, the Switch Expressions still remain in preview mode in this new version of the JDK.
Java 13, therefore, introduces the new yield keyword that must be used to return a value in an Expression Switch where the right side of the “case L ->” syntax is not just a simple expression.
Once the Switch Expression feature of Java 13 is enabled, the following code is valid:
Of course, it is always possible to use the “case L ->” syntax of traditional switch blocks within Switch Expressions by combining it with the use of the keyword yield :
It is important to know that the cases of a Switch Expression must be exhaustive. Thus, for all possible input values, there must be a corresponding switch label. Naturally, this obligation does not apply to traditional switch declarations.
In concrete terms, this means always defining a default clause within a Switch Expression.
The modifications made to the Switch Expressions in Java 13 are intended to prepare the ground for the future introduction of pattern matching in the JDK.
There is no known target version for this last feature. As always with Java, you will have to be patient.
3. Rewriting Of The Socket API
The implementation of the Java Socket API is very old since it dates back to JDK 1.0! It is mainly based on the java.net.Socket and java.net.ServerSocket classes. A rewriting of these classes and more generally of the Socket API was, therefore, necessary in order to provide the JDK with a more modern implementation.
For Java developers, this rewriting of the Socket API remains transparent in terms of usage.
Codes based on the old API remain compatible without any rewriting work. At the JDK level, however, this new implementation of the Socket API will provide a simpler and more modern code that will make debugging and maintenance easier for JDK developers.
In addition, this new implementation aims to promote its interoperability with Fibers, which are User-Mode Threads, currently being explored within the Loom project. As a reminder, this project plans to introduce a lighter competition model within the JDK.
On the latest prototypes available within OpenJDK, a new Fiber class has been added running in parallel with the Thread class. The future API made available to Java developers should be similar to that of the Thread class with two differences:
- A Fiber will encapsulate any task in a User-Mode work context. This will allow you to suspend and resume a task directly within the Java runtime rather than via the kernel.
- A User-Mode task scheduler, of the ForkJoinPool API type, will be used.
For the moment, no target version of the JDK has been announced for the Loom project.
To conclude on this rewrite of the Socket API, it is worth noting that the original implementations have not been removed from the JDK yet and that it is possible to continue using them by launching the JVM with the following option:
4. Improvements To The Garbage Collector ZGC
Not always mastered or well known by many Java developers, the Garbage Collector is an essential part of the Java virtual machine’s. As the JDK evolves, to meet the new needs of Java applications, new implementations have been proposed by Oracle or even by third-party contributors such as Red Hat for example.
Java 11 had thus seen the introduction of a low-latency Collector Garbage called ZGC. This Garbage Collector was offered on an experimental basis and targeted only 64-bit Linux environments.
With Java 13, ZGC has been improved to allow it to return unused heap memory to the underlying operating system. Currently, ZGC did not do this and this behavior was clearly not optimal for all types of applications and targeted environments. This was even more problematic in cases where the memory footprint is a major problem. For example:
- Container environments where resources are paid for on a pay-per-use basis.
- Environments where an application can remain inactive for long periods of time and compete with other applications for resources.
- An application that may have storage space requirements that will vary during its execution. Thus, the heap memory needed to start may be greater than what is needed after the runtime when the application is launched. It is, therefore, necessary to be able to adapt over the life of the application to these different needs.
Other Garbage Collectors, such as G1 or Shenandoah from Red Hat, already provide this capability today. Adding this capability to ZGC in Java 13 was, therefore, a necessity in order to facilitate its adoption in the future.
5. Dynamic CDS Archives
The latest major innovation introduced in Java 13 also does not directly affect Java developers since it is the JEP 350, which aims to extend data sharing between classes of an application running on the JVM. More commonly known as AppCDS, this feature should make it possible to dynamically archive classes at the end of an application’s execution.
Thus archived, the classes would include all classes of the application and code libraries loaded during their execution that are not present in the CDS base archive layer.
The addition of Dynamic CDS Archives to the JVM is intended to improve the usability of AppCDS and eliminate the need for users to perform different tests to create a list of classes for each application.
By reading these few lines, you will immediately understand that this new feature will affect a minority of Java developers. Nevertheless, it is always interesting to keep up to date on this type of new features added to the JDK.
Expected Features For Java 14
While Java 13 had not yet been released, the first rumors about the expected new features of Java 14 began to flourish in the middle of the summer. Among these rumors, we already have a near certainty since the JEP 352 has been officially included in the JDK 14.
This API aims to add mapping mode files to the JDK so that the FileChannel API can then be used to create instances of MappedByteBuffer objects referring to non-volatile memory. Again, this is a feature that will not make you dream as a Java developer.
The jpackage packaging tool for creating stand-alone Java application packages was intended to be experimentally integrated into Java 13. Finally removed from the JDK 13 scope, jpackage should probably be part of Java 14.
For the rest, we don’t know much more but we will learn more in the coming weeks because we must not forget that the JDK 14 will be made available on March 2020, i.e. in less than 6 months.
The new release pace of the JDK versions has been running smoothly for more than 2 years now. When you remember what we experienced in terms of carryover during the decade from Java 6 to Java 9, this is already a victory in itself for Oracle and the entire Java community.
The counterpart to these more frequent updates is new features that are much less exciting for Java developers and difficulties in tracking JDK updates.
The solution to this problem consists in being aware that the major versions of the JDK are now those with extended long-term support, while the major versions of the JDK that do not benefit from it are rather minor versions aimed mainly at changing the internal functioning of the JDK. For the Java developer, they contain small improvements that are good to know but will not upset their daily lives.
Other Java Articles You May Like to Explore
The 2019 Java Developer RoadMap
10 Things Java and Web Developer Should Learn in 2019
10 Testing Tools Java Developers Should Know
5 Frameworks Java Developers Should Learn in 2019
5 Courses to Learn Big Data and Apache Spark in Java
10 Courses to learn DevOps for Java Developers
10 Books Every Java Programmer Should Read
10 Tools Java Developers uses in their day-to-day work
10 Tips to become a better Java Developer