What is New in Java 15

Java 15 or JDK 15 is the reference implementation of the Java SE Platform with the version 15. It is released as an important feature and base for the Java17.

Java15 provides various new features, which are very exciting, incubator features and preview features for the JDK or Java development kit, which is a base for running a Java program.

In this article, the surroundings of Java 15 and its release dates, its, features, importance, projections and adoptions are going to be discussed in this article.

The following short-term release for the JDK platform is Java 15, which became generally available in September 2020. It adds some new improvements while also enhancing a number of features from previous releases.

Release of Java 15

Java 15 was made available on September 15, 2020, following the customary six-month release cycle. This was exactly six months after Java 14, which was released on March 17, 2020.

Mainly Java 15 or JDK 15 is the main source for the implementation of the Java SE Platform with the version of 15.

Java 15 consists of mainly 15 major improvements, which include the records and their preview features, Sealed classes and their preview features, Hidden classes and text blocks, and also a second incubator for foreign memory access of API.

For production systems requiring low-latency garbage collectors, the promotion of the ZGC and Shenandoah GC from experimental to production is likewise a significant boost.

The general release of Java 15 is slated for September 15, 2020. The release schedule's key dates are listed below.

1. 06/11/2020 is the release of Java 15 Ramp down Phase One, which is taken from the main line.
2. 16/07/2020 is the release date of Ramp down Phase Two in Java 15
3. 06/08/2020 is the release date of Java 15, which is the Initial Release Candidate.
4. 20/08/2020 is the release date of Java 15, which is the Final Release of the Candidate.
5. 15/09/2020 is the date when Java 15 released as General Availability.

Java EOL

Java 15 EOL OpenJDK 15 is a non-LTS version, and it continued to be supported for a total of six months after LTS expired in March 2021.

If the community agrees to alter its existing default support period, such plans could be affected. Of course, businesses like Azul will probably continue to charge for LTS services for OpenJDK versions that are not LTS.

Features of Java 15

The features of Java 15 include both major additions and deletions to Java, as well as the continuous availability of the pattern-matching capabilities described in Project Amber. The Nashorn JavaScript Engine has been deprecated, among other things.

JEP 358, which will make Null Pointer Exception to be set by default, is the last one (instead of requiring you to enable it manually). Below is the list of JEP numbers along with respective Java15 Features:

• JEP 378: Text Blocks (Standard)
• JEP 371: Hidden Classes -
• JEP 360: Sealed Classes (Preview) -
• JEP 375: Pattern Matching, for instance of (Second Preview)
• JEP 384: Records (Second Preview)
• JEP 372: Disable the Nashorn JavaScript Engine
• JEP 373: Reimplement the Legacy DatagramSocket API
• JEP 374: Disable and Deprecate Biased Locking
• JEP 379: A Low-Pause-Time Garbage Collector: Shenandoah
• JEP 383: Foreign-Memory Access API (Second Incubator) -
• JEP 381: Remove the Solaris and SPARC Ports
• JEP 385: Deprecate RMI Activation for Removal

The preview addition of sealed classes, which aid developers in precisely outlining possible subtypes while setting the foundation for more pattern-matching advancements, is arguably the biggest new innovation for JDK 15.

Let's discuss Each feature in Detail:

1. JEP 360- Sealed Classes (Preview):

As previously mentioned, sealed classes provide a more exact method of declaring possible subclasses within a superclass. In essence, sealed classes assist minimize unwanted expansion while facilitating access to super classes.

Only classes and interfaces with the appropriate permissions may extend or implement a sealed class or interface.

Kotlin has had sealed classes feature for a time, and Java 15 now offers this functionality for finer control over the inheritance.

Sealed classes, as their name suggests, allow you to restrict or allow class hierarchies to only particular kinds.

Given that you only have a limited number of classes to swap between, this is tremendously helpful for pattern matching.

Java does not currently offer fine-grained inheritance control. Very coarse-grained control is offered by access modifiers like public, protected, and private, as well as the default package private.

In order to achieve this, sealed classes enable classes to designate which types can be used as sub-types. This also holds true for the categorization of types that can implement interfaces.

Extending a sealed class is done same as what we have used in Java extends as a keyword.

So from that, we can write as:

If any class extends a sealed class, it must itself should be declared with the keywords of sealed, non-sealed, or final. By declaring all these the compiler will ensure the class hierarchy, and it should also remain constant.

The major benefit of using the sealed classes are finite and exhaustive hierarchy. Let us examine all these situations as an action or an example:

Without a sealed class, the compiler cannot fairly infer that our if-else expressions cover every potential subclass. If there weren't an otherwise clause at the end, the compiler would probably alert us that our logic doesn't account for all scenarios.

In below example, you don't need to use the keywords as it allows the compiler to take care of it implicitly... because you declared the classes Plain, Tractor, and Train in the same file as Driver:

As you can see above, we have specified what each class's final modification will be. Here is a crucial sealed class rule that you must remember: Every allowed class must be explicitly set with a modifier. Either final, sealed, or unsealed is possible.

The effects of each modifier on inheritance are as follows:

• When an authorized subclass is marked final, it cannot be further extended.
• An authorized subclass that has been declared sealed can only be expanded by classes that the subclass permits.
• An authorized subclass may be extended further by any class and may be designated non-sealed. The subclasses below in the class hierarchy cannot be constrained by the superclass.

Let us take as an example of a simple calculator, which will also allow us to perform the mathematical expressions like addition, subtraction, multiplication, and division, like various examples. Using the sealed classes, we can also take a BinaryExpression interface which helps the cloud developer and explicitly permits only those four implementations.

There is no need for a catch-all else block or the default section in a switch if you know exactly which subtypes exist. The latter is crucial for Pattern Matching in the future because, for sealed classes, the javac compiler can determine whether the switch is exhaustive. Similar to this, you know that your format supports all potential subtypes when serialising data to formats with schemas, like xml.

2. Records (Second preview):

To lessen boilerplate code when creating POJO-based data carrier classes, records were added as a preview feature in Java 14. Data classes, which are a long-standing feature of Kotlin, already have this.

Records receive their second peek as of Java 15 at this time. There are a few minor additions but several significant clarifications and limitations that you should be aware of even though there aren't any significant changes:

• Before Java 15, native methods could be declared in records. However, it wasn't a smart idea. Native method declaration is now expressly forbidden by the JEP in records. Understandably, adding an external state requirement by introducing a native function takes away from records' USP.
• It is not recommended to modify the implicitly declared fields that correspond to the record components of a record class via reflection at this time since doing so would result in an IllegalAccessException.

You must absolutely refrain from defining native methods in records because they are designed to be data carrier classes.

The Java records feature is now in its second preview phase, as per JEP 384. Records offer an easier, more comprehensible approach to build data aggregate classes than was originally proposed in JEP 359. One of the major advantages of the records feature is that it makes it unnecessary to evaluate the meaning and intent of boilerplate code.

The constructor's prohibition of this, which enforces the "auto initialised" idiom of the record's compact function Object() { [native code] }, is the major change between the second and first previews. Additionally, JEP 384 gives Java users a longer review period.

Without Records:

It's important to note that a lot of code is required to generate an immutable object, which serves only to store the state. We have a single all-arguments function Object() { [native code] }, a final function Object() { [native code] } for all of our fields, and an accessor function for each field. In extreme circumstances, we might even designate the class as final to forbid subclassing.

To produce useful logging output, we would frequently go one step further and alter the function toString() { [native code] } method. When comparing two instances of these objects, we would likely also want to override the equals and hashCode methods to prevent undesirable outcomes.

With Records:

We can define the same immutable data object in a much more condensed manner by using the new record class:

Here, a few events have taken place. The class definition contains a new syntax that is tailored specifically for records. We give information on the fields that make up the record in this header.

The compiler can deduce the internal fields using this header. This means that since they are already present by default, we don't need to create any explicit member variables or accessors. We are not required to offer a function Object() { [native code] } either.

The function toString() { [native code] }, equals, and hashCode functions are also given sensible implementations by the compiler.

Records do allow us to modify some of the default behaviors even though they do away with a lot of boilerplate code. We could, for instance, create a canonical function Object() { [native code] } that does some validation:

It's important to note that there are some limitations on records. They cannot be declared abstract, they cannot use native methods, and they are always final.

Local Records:

In order to hold intermediate values, records can also be defined within procedures. A local record is implicitly static unlike local classes. This stops values from being captured by the record and means they can't access variables and instance members of the enclosing methods, which is actually wonderful.

Java developers who previously had to write helper records now have the benefit of local records.

3. Hidden Classes:

Java 15 will include a new feature called hidden classes. They won't directly assist most developers, but they will likely be helpful to anyone who works with dynamic bytecode or JVM languages.

The purpose of hidden classes is to enable the construction of undiscoverable classes during runtime. As a result, neither other classes nor reflection can link to them or reveal them. Hidden classes are made to be effective at both loading and unloading because classes like these often have a brief lifecycle.

It should be noted that recent Java versions do permit the construction of anonymous classes that resemble hidden classes. They rely on the Unsafe API, nevertheless. There is no such dependency in hidden classes.

For Java 15, in addition, the normal Java developer won't be in directly contact with hidden classes, but anyone working with proxies or other dynamically generated at runtime will probably be using them. Hidden classes' primary purpose is to produce classes that "cannot be used directly by the bytecode of other classes."

In the shape of JVM anonymous classes, the idea of hidden classes already exists (not to be confused with anonymous inner classes in the source code). Defining such classes formerly required the use of Unsafe, but this JEP adds a supported API for doing so.

4. Text Blocks:

Text Blocks are now planned for inclusion as a full feature in Java 15 following a second preview round in Java 14 that added two new escape sequences. Text blocks were first envisioned as raw string literals under JEP 326 for Java 12, in case you haven't been following the raw string literal tale. Raw string literals were later removed and reintroduced as a more developed feature under JEP 355: Text Blocks (Preview). Text blocks will now offer developers a mechanism to predictably format multi-line string literals with considerations for avoiding the majority of escape sequences as a fully-fledged feature. Our blog on text blocks is worth reading if you want to find out more about text blocks and all their variations.

5. Foreign Memory API:

Foreign memory access is already a Java 14 feature that is in development. The objective of Java 15 is to maintain its incubation status while introducing a number of new features:

• To tailor memory access var handles, a new VarHandle API has been developed.
• Support for a memory segment's concurrent processing using the Spliterator interface
• improved assistance with mapped memory segments.
• The capacity to modify and dereference addresses originating from sources such as native calls.

Memory that is located outside the managed JVM heap is referred to as "foreign memory" in general. As a result, it is not subject to garbage collection and frequently manages extremely large memory segments.

Most developers won't be directly impacted by these new APIs, but third-party libraries that deal with foreign memory will benefit greatly from them. Distributed caches, denormalized document stores, big arbitrary byte buffers, memory-mapped files, and more fall under this category.

6. Remove the Nasorn JavaScript Engine:

In an effort to accommodate additional dynamic languages in the JVM, the Nashorn JavaScript Engine was added to JDK 8 as a potential alternative for the Rhino scripting engine. However, since the launch of GraalVM, that area has become the centre of attention for multi-language support. Although Nashorn was initially intended to be removed in Java 11, it remained a part of the JDK until JDK 14. This alteration doesn't have much of an effect, yet it's significant because it denotes a split.

Conclusion:

In terms of significant features, Java 15 is a sizable version. Since many of the innovations are supported by well-known Java developers, we anticipate that many of these preview and incubatory features will mature into full features before Java 17.

However, we don't see Java 15 being a resounding success in terms of adoption. Utilizing these features just to relocate six months later isn't worth the time or money for the majority of teams. The actual query is how much these changes will influence Java 17's adoption as the following LTS version.

We can anticipate Java 16, which will be quickly followed by a new long-term-support version in Java 17.