See how Java 16 is changing sealed classes, instanceof, and many of its most popular APIs.
Join the DZone community and get the full member experience. How time flies! Even in these extraordinary times, it seems hard to believe another six months have passed, and we now have a new release of the JDK. As usual, I will summarise all the new features with some commentary on their potential impact on Java application development. Not all releases are created equal and, depending on how feature development phases align; some will have more features than others. JDK 16 contains quite a few new things, although several of them are continuations or finalization of incubator modules or preview features from earlier releases. I think this is one of the biggest benefits of the faster release cadence. Providing new functionality without making it part of the standard, gathering feedback from developers, and potentially making changes has delivered an improved process for the JDK development. I’ll take my usual approach of dividing the post into language changes, library additions, JVM-related updates and, finally, anything else. There are no new syntax constructs in JDK 16, but there are still several significant changes. This was introduced as a preview feature in JDK 14 and continued in preview mode in JDK 15. This feature has been finalized in JDK 16. It is included in the Java SE 16 Language Specification and does not require the –enable-preview command line flag for compilation and runtime. There are two minor changes to how the feature worked in JDK 15. The first is that pattern variables are no longer implicitly final. This is a very logical change since local variables are not treated as implicitly final. The second change is that is now a compile-time error for a pattern instanceof expression to compare an expression of type S against a pattern of type T, where S is a subtype of T. Here’s an example: This will result in a compiler error: This seems logical, since the if statement is redundant as the predicate would always evaluate to true. Another preview feature introduced in JDK 14 and now finalized in JDK 16. For me, this is a beneficial addition to the Java language, as we finally have a simple way to deal with tuples. The only change to Records from the JDK 15 implementation is to relax the longstanding restriction whereby an inner class cannot declare a member that is explicitly or implicitly static. This is very useful for simplifying certain stream operations. Often it is desirable to have a stream pass more than one object for each element. Now, a local record can be defined reducing the type pollution that would otherwise result. This was introduced as a preview feature in JDK 15 and continues as one in JDK 16. There are three changes: There are four new libraries defined through individual JEPs: Not to be confused with the deprecated Vector class in the collections API, this is a library to enable developers to better use underlying CPU vector capabilities. All modern processors have single instruction, multiple data (SIMD) capabilities. Multiple elements of an array can be loaded into very wide registers, such as the 512-bit AVX-512 on specific Intel processors. For example, a single operation, adding 10 to each value, can be performed in a single machine instruction cycle, significantly improving the performance of numerically intensive code. The problem is that the compiler needs to recognize code that can be turned into vector operations, and this can be very hard, especially if there are conditional operations involved. The vector API provides a mechanism for developers to make it explicit to the compiler that vector operations should be used. This does, however, make the code more complicated. First, it is necessary to obtain a vector species. This is the form of the vector that is required, both in terms of the size of the register to be used and the type of the data to be loaded, such as a float. Type-specific vectors are then created and loaded, as required, with values. The final part is to manipulate the vectors using the appropriate mathematical functions. All of this can be seen in the example lifted from the JEP. This is provided as an incubator module, so subject to change before being included in the Java SE standard. I hope that the developers will realize that using abbreviations is not necessary (or ideal). I would much rather see multiply() than mul() and so on. UNIX domain sockets have been around for a long time, dating all the way back to the BSD variant in 1983. However, it wasn’t until 2018 that these were introduced in the Windows platform. Since Java prides itself on being cross-platform, it didn’t make a lot of sense to have a library that couldn’t run anywhere. Now we have the UNIX domain sockets API, which provides an easy way to handle interprocess communication on a single host.
