Java programming language has undergone several changes since JDK 1.0 as well as numerous additions of classes and packages to the standard library. The evolution of the Java language has been governed by the Java Community Process (JCP) since J2 Standard Edition 1.4, which uses Java Specification Requests (JSRs) to propose and specify additions and changes to the Java platform. The Java language is specified by the Java Language Specification (JLS) and changes to the JLS are managed under JSR 901. Java 14 is set to release in March 2020. Below are the features of the new update.
- Pattern Matching for instanceof
- Non-Volatile Mapped Byte Buffers
- Helpful NullPointerExceptions
- Switch Expressions (Standard)
- Packaging Tool (Incubator)
- NUMA-Aware Memory Allocation for G1
- JFR Event Streaming
- Records (Preview)
- Deprecate the Solaris and SPARC Ports
- Remove the Concurrent Mark Sweep (CMS) Garbage Collector
- ZGC on macOS
- ZGC on Windows
- Deprecate the ParallelScavenge + SerialOld GC Combination
- Remove the Pack200 Tools and API
- Text Blocks (Second Preview)
- Foreign-Memory Access API
Pattern Matching For Instanceof
JEP will improve the Java Programming language with pattern matching for the operator instanceOf. Pattern matching allows a clearer expression of a common logic in a system, particularly the conditional removal of parts from objects.
Before Java 14
if (obj instanceof String) {
String str = (String) obj; // need to declare and cast again the object
.. str.contains(..) ..
}else{
str = ....
}
Java 14 Enhancements
if (!(obj instanceof String str)) {
.. str.contains(..) .. // no need to declare str object again with casting
} else {
.. str....
}
Another Example
if (obj instanceof String str && str.length() > 5) {.. str.contains(..) ..}
if (obj instanceof String str || str.length() > 5) {.. str.contains(..) ..}
NOTE: instanceOf can solely match if the object isn't null then it is appointed to str. the utilization of pattern matching in instanceOf ought to scale back the variety of specific casts within the Java programs.
Non-Volatile Mapped Byte Buffers
To give a high-level summary, Java NIO (New IO) File API is there since JDK 1.4, FileChannel with MappedByteBuffer to load the portion of a file information into the Virtual memory VM, then new improvement has been introduced referred to as, Path. The Path is the interface that replaces java.io.File class as illustration of a file or a directory in Java NIO.
Now JEP is targeting for improvement in MappedByteBuffer to load the part of file data in non-volatile memory (NVM). Nonvolatile memory is a system storage, where information wouldn't be lost/deleted even if the power is turned off like read-only memory (ROM), nonvolatile storage, storage devices like hard disk etc. And in the case of volatile, it does not keep information if power is turned off like RAM. The sole API modification needed is a new enumeration utilized by FileChannel clients to request mapping of a file located on NVM-backed file system instead of a traditional, file storage system.
Risks And Assumptions
This implementation permits for management of NVM as off-heap resource via a ByteBuffer. A related improvement, JDK-8153111, is gazing the utilization of NVM for heap information. It may be necessary to consider use of NVM to store JVM data. These completely different modes of NVM management might end up to be incompatible or, possibly, inappropriate once utilized in combination. The projected API can only deal with mapped regions up to 2GB. It's going to be necessary to revise the projected implementation so it conforms to changes projected in JDK-8180628 to beat this restriction.
Helpful NullPointerExceptions
Improvement in NullPointerExceptions exception message generated by JVM. It'll be useful information to developers and support employees concerning the premature termination of a program. Since NPEs will occur where in a program, it's usually impractical to try to catch and recover from them. As a result, developers consider the JVM to pinpoint the supply of NPE when it truly happens. As an example, suppose NPE happens during this code:
a.i = 99;
The JVM will print out the method, filename, and line number that caused the NPE:
Exception in thread "main" java.lang.NullPointerException
at Prog.main(Prog.java:5)
Suppose An NPE Occurs In This Code
a.b.c.i = 99;
The file name and line number don't pinpoint specifically that which variable was null. Was it a or b or c? Currently JDK14 JEP has been updating this exception to be thrown as given below to know precisely which variable was null.
Exception in thread "main" java.lang.NullPointerException:
Cannot read field 'c' because 'a.b' is null.
at Prog.main(Prog.java:5)
However, there are some Risks. The null-detail message might contain variable names from the source code. Exposing this information may be thought of as a security risk.
Switch Expressions (Standard)
JEP 14 is attending to extend switch statement, which can be used as expression with USE of an arrow (->), and will yield/return the value.
Example
Before Java 14
switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
System.out.println(6);
break;
case TUESDAY:
System.out.println(7);
break;
case THURSDAY:
case SATURDAY:
System.out.println(8);
break;
case WEDNESDAY:
System.out.println(9);
break;
}
Java 14 enhancements
switch (day) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
case TUESDAY -> System.out.println(7);
case THURSDAY, SATURDAY -> System.out.println(8);
case WEDNESDAY -> System.out.println(9);
}
Another Example
Before Java 14
int numLetters;
switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
numLetters = 6;
break;
case TUESDAY:
numLetters = 7;
break;
case THURSDAY:
case SATURDAY:
numLetters = 8;
break;
case WEDNESDAY:
numLetters = 9;
break;
default:
throw new IllegalStateException("Wat: " + day);
}
Java 14 Enhancements
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};
Another Example
//Arrow labels
static void grade(int g) {
System.out.println(
switch (g) {
case 1 -> "A";
case 2 -> "B";
default -> "C";
}
);
}
------------------------------------------
//Yielding a value - introduce a new yield
int j = switch (day) {
case MONDAY -> 0;
case TUESDAY -> 1;
default -> {
int d = day.toString().length();
int result = f(d);
yield result;
}
};
Example
Before
final class Point {
public final int x;
public final int y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
// state-based implementations of equals, hashCode, toString
// nothing else
Java 14 With Records
record Point(int x, int y) { }
Limitation Of Using Records
- Records cannot extend the other category, and can't declare instance fields aside from the private final fields that correspond to elements of the state description.
- Records are implicitly final, and can't be abstract, such limitations mark that a record's API is entirely outlined by its state definition and may not be changed by another category or record later.
Deprecate the Solaris and SPARC Ports
Deprecate Solaris / SPARC, Solaris / x64, and UNIX / SPARC ports so as to get rid of them in the future.
By removing support for these ports, contributors within the OpenJDK community are ready to accelerate the development of new features to maneuver the platform forward.
Build-Configuration Changes
The following should result in an attempt to configure a Solaris and/or SPARC
The new --enable-deprecated-ports=yes configuration option will suppress the error and proceed.
$ bash ./configure --enable-deprecated-ports=yes
...
checking compilation type... native
configure: WARNING: The Solaris and SPARC ports are deprecated and may be removed in a future release.
...
Build performance summary:
* Cores to use: 32
* Memory limit: 96601 MB
Configuring a build for Solaris and SPARC (including Solaris / SPARC, Solaris / x64, Linux / SPARC) will issue the error / warning.
Remove The Concurrent Mark Sweep (CMS) Garbage Collector
Java 14 is planned to get rid of the Concurrent Mark Sweep (CMS) garbage collector.
This update will deactivate CMS compilation, take away content of the gc / cms directory from the supply tree, and remove CMS-only options.
The following warning message will result in the attempt to use CMS via the -XX:+UseConcMarkSweepGC option
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; \
support was removed in <version>
VM will keep running using the default collector.
JEP 364 - ZGC On MacOS
JEP 364 is similar to JEP 365. Only JEP 364 offers the Z Garbage Collector (ZGC) for MacOS. It ports the ZGC garbage collector to macOS. A Part of the JEP is also the collector's functionality for liberating unused device memory, as expressed in JEP 351, this has been since since Java 13. The macOS implementation of ZGC contains two parts:
Support for multi-mapping memory on macOS.
Support in ZGC for discontinuous memory reservations.
JEP 365 - ZGC Garbage Collector On Windows
JEP 365 is practically the same as JEP 364. Only JEP 365 offers the Z Garbage Collector (ZGC) for Windows.
Most of the ZGC code base is platform independent and doesn’t need Windows-specific changes. Supporting Windows 10 and Windows Server older than version 1803 isn’t a goal, since older versions lack the important API required for memory reservations.
The Windows Implementation Of ZGC Needs The Subsequent Work:
Support For Multi-Mapping Memory
The use of colored pointers by ZGC needs multi-mapping support, so that the identical physical memory can be accessed from multiple locations within the process address area. On Windows, paging-file backed memory provides an identity (a handle) to physical memory which is unrelated to the virtual address where it’s mapped using the identity permits ZGC to map the identical physical memory to multiple locations.
Support For Mapping Paging-File Backed Memory Into A Reserved Address Space
The Windows memory management API isn’t as versatile as POSIX's mmap/munmap, especially when it comes to mapping file backed memory into a previously reserved address area region. For this purpose, ZGC will use the Windows idea of address space placeholders. In version 1803 of Windows 10 and Windows Server, the placeholder idea was introduced. ZGC support won’t be implemented to older versions of Windows.
Support For Mapping And Unmapping Arbitrary Elements Of The Heap
ZGC's heap layout needs support for mapping and unmapping arbitrary heap granules together with its dynamic size (and re-sizing) of heap pages. This demand in combination with Windows address area placeholders needs special attention because placeholders must be explicitly split / amalgamated by the program rather than automatically split / coalesced by the operating system (as with Linux).
Support For Committing And Uncommitting Arbitrary Elements Of The Heap
ZGC will dynamically commit and uncommitted physical memory while the Java program works. To support these operations, the physical memory will be divided and backed by multiple paging-file segments. Every paging-file section corresponds to a ZGC heap granule and can be committed and uncommitted independently of other sections.
JEP 366 - Deprecate The ParallelScavenge + SerialOld GC Combination
JEP 366 involves garbage collector, and it targets to deprecate the mixture of the Parallel Scavenge and Serial Old garbage collection algorithms. Besides decreasing the combination -XX:+UseParallelGC-XX :- UseParallelOldGC, the -XX: UseParallelOld GC option is also decreased as it is used to deselect the old-generation parallel GC, thereby enabling the serial old generation GC. As a result, any intentional use of the option UseParallelOldGC will show deprecation warning.
JEP 367: Remove The Pack200 Tools And API
Pack200 is a JAR file compression scheme implemented by JSR 200 in Java SE 5.0.
Remove the pack200 and unpack200 tools and also the pack200 API from the java.util.jar package. These tools and APIs are deprecated for removal in Java SE 11 with the intention of removing them in a future release. In the JDK feature release for which this JEP is eventually meant, three types will be removed in the Java. Base module previously annotated with @Deprecated(forRemoval = true):
java.util.jar.Pack200
java.util.jar.Pack200.Packer
java.util.jar.Pack200.Unpacker
JEP 368: Text Blocks (Second Preview)
In Java, to implant HTML, XML, SQL, or JSON snippet into a code is commonly hard to read and hard to keep, and to overcome this problem, Java 14 has introduced Text Block.
A text block contains zero or more content characters, those are enclosed by open and shut delimiters.
HTML Example Without Text Block
String html = "<html>\n" +
" <body>\n" +
" </body>\n" +
"</h <p>Hello, world</p>\n" +
" tml>\n";
The opening delimiter is a sequence of three double quote characters (""") followed by zero or more white areas followed by a line terminator. The content begins at the primary character after the line terminator of the opening delimiter.
The closing delimiter is a sequence of three double quote characters. The content ends at the last character before the first double quote of the closing delimiter.
The content may include double quote characters directly, unlike the characters in a string literal. The use of \" in a text block is permitted, but not necessary or recommended. Fat delimiters (""") were chosen so that " characters could appear unescaped, and also to visually distinguish a text block from a string literal.
A text block is a multi-line string literal which prevents the need for most escape sequences, formats the string automatically, and allows the developer and gives control to format the string if necessary.
HTML Example with Text Block
String html = """
<html>
<body>
<p>Hello, world</p>
</body>
</html>
""";
In early 2019, JEP 355 proposed text blocks as a follow-up to the JEP 326 (Raw String literals) exploration, which had been withdrawn.
In mid-2019, JDK 13 introduced Text Block Preview feature, which then re-visited by adding below two new escape sequences in Java 14.
Two new escape sequences are newlines (line-terminator) denoted by \ and second is for white space (single space) denoted by /s.
Newlines Example
// Without Text Block
String literal = "two escape sequences first is for newlines " +
"and, second is to signify white space " +
"or single space.";
// With the \<line-terminator> escape sequence this could be expressed as:
String text = """
two escape sequences first is for newlines \
and, second is to signify white space \
or single space.\
""";
White Space Or Single Space Example
// Using \s at the end of each line in this example
guarantees that each line is exactly six characters long
String colors = """
aaa\s
bbb\s
ccc\s
""";
If you have a requirement of Java Development, Contact us.
