Java has been a programmer’s dream and what’s the better way to quantify Java’s popularity with the new version release Java 13. After the initial Java enhancement proposal, there have been advancements in JDK features that will blow up Java developer’s mind with a new range of features after the official release on September 17, 2019.
But Why do you think Java is so popular?
Java has been a craze among programmers due to its platform independence and the ability to run on different computers. It has been there for so long that it has been adopted by organizations like banks, insurance companies, enterprises, agencies and mostly by software outsourcing companies.
Java has been there in the business to develop android apps, java web applications, software tools, and scientific applications.
Let us delve into the stats and gauge the popularity ratio of Java applications among other competing programming languages.
As per the recent September report by Tiobe Index, Java applications and programmers has been beholding onto its position and has been giving a tough time to other programming languages.
After seeing the popularity tribe of Java among the other programming languages, let’s move over to Java 13 JDK’s features in a glance:
- JEP 350: Dynamic CDS Archives
- JEP 351: ZGC: Uncommit Unused Memory
- JEP 353: Reimplement the Legacy Socket API
- JEP 354: Switch Expressions (Preview)
- JEP 355: Text Blocks (Preview)
Since we can't expect a lot of changes after the initial release of Java 12, still there changes at a functional level that could move over Java programmers to new stable features. The goal is to finalize the preview features by the next LTS version so that they are stable enough and will look good for the next three years. It has been expected that by September 2021, Java 17 will take over the legacy of Java 8 and 11.
In this blog, I am going to take you through the latest features that you can expect from Java 13.
-> Dynamic CDS Archives
Apart from the new features that are obvious to Java developers, a lot has happened under the roof of JVM and in-class library. Class Data Sharing (CDS) was introduced back during Java 5. The ultimate goal of CDS is to shorten the start times of Java applications by storing certain information about classes in Class Data Sharing archives. The data can then be loaded at runtime and used by several JVMs.
Until Java 10, however, the shared archives were only accessible for the Bootstrap ClassLoader. Starting with Java 10, CDS was extended by Application Class Data Sharing (AppCDS). AppCDS enables the built-in system and platform class loader as well as user-defined class loaders to access the CDS archives. Class lists are required to create the CDS archives in order to identify the classes to be loaded.
Previously, these class lists had to be determined by trial runs of the application to determine which classes were actually loaded during execution. Since Java 12, default CDS archives are delivered with the JDK by default, which is based on the class list of the JDK.
Dynamic CDS Archives now build on this. The goal is to save the additional test runs of the application. After an application has been executed, only the newly loaded application and library classes that are not already contained in the Default/Base Layer CDS are archived. Dynamic archiving is activated with command-line commands. In a future extension, the archiving of classes could then run completely automatically and transparently.
-> ZGC: Uncommit Unused Memory
Nowadays, it is not so uncommon that the applications have to serve thousands of users at the same time. Such applications need a lot of memory and the management of memory is significant that affects the performance of the application. To meet the stated requirements, Oracle has introduced the Z Garbage Collector (ZGC) in Java 11 as it promises very short pauses when cleaning up heap memories with several terabytes.
Previously, it didn't release the heap memory released reserved for applications. As a result, applications consume far more memory than necessary. An application that runs in low-resource environments is particularly affected. Other garbage collectors such as the G1 and Shenandoah already support the release of unused memory.
-> Renewed Socket APIs
The Java Socket and Java ServerSocketAPIs are fragments from the JDK 1.0. Most of them consist of legacy from Java and C Code. This makes the maintenance and extensibility much more difficult. The NioSocketImpl is supposed to replace the outdated PlainSocketImpl now. NioSocketImpl is already based on existing New I/O implementation and uses its existing infrastructure in the JDK.
The previous implementation is not compatible with other planned extensions of the language. For example, concurrency problems hinder the future use of the lightweight user threads (fiber, part of the Project Loom).
-> Enhancements for Switch Expressions
If you look at the feature from the developer’s point of view, then it is the point that is merely interesting. For example, the Switch Expressions was introduced as a preview in Java 12 and it has been extended due to user feedback. The Switch Expressions are an alternative to the cumbersome and error-prone switch statements.
The biggest change in the coding norms that could be seen in Java 13 is the replacement of the keyword break in the switch expression by yield. The background is the better differentiation between a switch statement ( with possible break) and expressions (with yield). The yield statement exits the switch and returns the result of the current branch, similar to a return.
For instance, the below code snippet showcases the scenario where Switch's statement has been used with break and in the other part Switch Expression has been used with the yield to make through the difference between the two.
-> Text Blocks instead of Raw String Literals
text block is a new kind to define string literal in the Java language. It may be used to denote a string anywhere that a string literal may be used but offers greater expressiveness and less accidental complexity. The first implementation of Raw String Literals has raised many questions as users have given feedback around the same that has stirred multiple questions.
After all, many Java applications can process code snippets from other languages such as HTML or SQL. Until now, such strings could only be defined in a cumbersome way, which makes them difficult to read.
For example, extra control commands (escaping with \n) must be used for line breaks. Other languages such as Groovy, Scala or Kotlin have long offered the possibility of defining multi-line texts.
The new text block uses triple quotation marks as delimiters and can be used wherever normal strings are allowed.
The code snippet below explains the difference between the two:
The opening and closing triple quotes must be in a separate line. Nevertheless, the actual content starts with the second line. This increases the readability of the source code, as the indentation of the first line is displayed correctly in the source text.
Conclusion:
The changes described so far were defined in the JEPs ( Java Enhancement Protocols). There are however further adaptations directly in the class library. But first, you have to install Java 13 while Java 14 version is still in pipeline.
The changes are uncertain and there have been certain features such as Switch Expressions and Text Block that can be finalized. However, the next release is on its way.
