Java 14
Java 14 has been released last Tuesday (17 March 2020), the new features are:
―JEP 305: Pattern Matching for instanceof (Preview)
―JEP 343: Packaging Tool (Incubator)
―JEP 345: NUMA-Aware Memory Allocation for G1
―JEP 349: JFR Event Streaming
―JEP 352: Non-Volatile Mapped Byte Buffers
―JEP 358: Helpful NullPointerExceptions
―JEP 359: Records
―JEP 361: Switch Expressions (Standard)
―JEP 362: Deprecate the Solaris and SPARC Ports
―JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
―JEP 364-365: ZGC on macOS and Windows
―JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
―JEP 367: Remove the Pack200 Tools and API
―JEP 368: Text Blocks (Second Preview)
―JEP 370: Foreign-Memory Access API (Incubator)
Here some details of some of them:
JAVA 14: JEP 305: Pattern Matching for instanceof (Preview)
Over the course of Project Amber, pattern matching for Java is being worked on. For the instanceof operator, pattern matching in Java 14 could become a reality, making the Java programming language more concise and secure. With pattern matching, the “form” of objects can be precisely defined, after which they are tested against their own input by statements and expressions.
The use of pattern matching in instanceof could lead to a strong decrease of necessary type conversions in Java applications. In future Java versions, pattern matching could be used for further language constructs such as switch expressions.
Writing equals() will get much nicer:
@Override
public boolean equals(Object o) {
if (o == this) return true;
if (!(o instanceof Money))
return false;
Money other = (Money)o;
return this.amount == other.amount
&& Objects.equals(this.currencyCode, other.currencyCode);
}
Becomes:
@Override
public boolean equals(Object o) {
if (o == this) return true;
return (o instanceof Money other
&& this.amount == other.amount
&& Objects.equals(this.currencyCode, other.currencyCode));
}
https://openjdk.java.net/jeps/305
JEP 343: Packaging Tool (Incubator), Create a tool for packaging self-contained Java applications.
With JDK 8, a tool called javapackager was released as part of the JavaFX kit. However, after JavaFX split from Java with the release of JDK 11, the popular javapackager was no longer available.
The packaging tool ensured that Java applications could be packaged in such a way that they could be installed like all other programs. For Windows users, for example, *.exe files could be created and their Java application installed by double-clicking. Since the tool is sorely missed, a new tool called jpackage is to pick up the mantle. Users can finally create their own Java installation files again, based on the Java application and a runtime image. The tool takes this input and creates an image of a Java application that contains all dependencies (formats: msi, exe, pkg in a dmg, app in a dmg, deb and rpm).
Commands to package non modular application:
$ jpackage --name myapp --input lib --main-jar main.jar
Commands to package modular application:
$ jpackage --name myapp --module-path lib -m myapp
It is installed by default in "C:/Program Files/".
https://openjdk.java.net/jeps/343
JEP 345: NUMA-Aware Memory Allocation for G1
Multi-core processors are now the general standard.
In a NUMA( non-uniform memory access) memory architecture, each processor core receives a small amount of local memory, but the other cores are granted access to it.
JEP 345 plans to equip the G1 Garbage Collector with the possibility to use such architectures advantageously.
Among other things, this is intended to increase performance on very powerful machines.
JEP 345 serves exclusively for the implementation of NUMA support for the G1 garbage collector, only for memory management (memory allocation) and also only under Linux.
Whether this support of NUMA architectures also comes for other garbage collectors or for other parts such as task queue stealing is not known.
Concretely, G1's heap is organized as a collection of fixed-size regions.
If the +XX:+UseNUMA option is specified then, when the JVM is initialized, the regions will be evenly spread across the total number of available NUMA nodes.
https://openjdk.java.net/jeps/345
JEP 349: JFR Event Streaming, Expose JDK Flight Recorder data for continuous monitoring
―Define:
To consume the data today from JFR, a user must start a recording, stop it, dump the contents to disk and then parse the recording file.
This works well for application profiling, where typically at least a minute of data is being recorded at a time, but not for monitoring purposes.
With JEP 349, it is proposed to create an API, via which the data collected by the JFR can be used for the continuous monitoring of active and inactive applications.
―Snippet:
//Prints the overall CPU usage and locks contended for more than 10 ms.
try (var rs = new RecordingStream()) {
rs.enable("jdk.CPULoad").withPeriod(Duration.ofSeconds(1));
rs.enable("jdk.JavaMonitorEnter").withThreshold(Duration.ofMillis(10));
rs.onEvent("jdk.CPULoad", event -> {
System.out.println(event.getFloat("machineTotal"));
});
rs.onEvent("jdk.JavaMonitorEnter", event -> {
System.out.println(event.getClass("monitorClass"));
});
rs.start();
}
https://openjdk.java.net/jeps/349
JEP 359 Records for modeling data as data
JEP 359 brings records as preview feature for Java.
Records is a new type. It use the keyword 'record' as you would use the keyword 'class'.
It provides a compact syntax for declaring classes which are transparent holders for shallowly immutable data. It is a more restricted kind of class.
A record is “the state, the whole state and nothing but the state”.
It consists of a name, the status description and the body:
record Person (String firstName, String lastName) {
static int x;
public static void doX() {
x++;
}
public String getFullName() {
return firstName + " " + lastName;
}
}
Even if it is not the primary goal,'record' skims boilerplate code like accessors, equals(), hashCode(), toString().
Records remain classes, even if they are restricted.
For example, they can contain annotations or Javadocs,
and declare their bodies as static fields, methods, constructors, or instance methods.
What they cannot do, however, is extend other classes or declare instance fields.
https://openjdk.java.net/jeps/359
JEP 361: Switch Expressions (Standard)
With JEP 325 (Switch Expressions), it was proposed to extend the switch statement so that it can be used either as a statement or as an expression.
Both forms should be able to use either “traditional” or “simplified” variables and control structures.
The aim of this JEP was to simplify daily programming and pave the way for Pattern Matching (JEP 305).
It changes the case notation.
In addition to the obvious arrow instead of the colon, several values can also be listed for testing purposes since Java 12.
No break is needed anymore.
With JEP 354 Gavin Bierman suggested to adapt the functionality a little bit.
To output a value from a switch expression, the value statement is to be replaced by a yield statement.
―Arrow labels
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};
―Yielding a result
int j = switch (day) {
case MONDAY -> 0;
case TUESDAY -> 1;
default -> {
int k = day.toString().length();
int result = f(k);
yield result;
}
};
https://openjdk.java.net/jeps/361
JEP 362: Deprecate the Solaris and SPARC Ports
In computing, to port means to transfer (software) from one system or machine to another.
"the software can be ported to practically any platform"
So when saying "Deprecate the Solaris and SPARC Ports" means that Java will no more take charge of the Solaris/SPARC platform.
The effort to make Java run on such platforms will be granted to other new Java features.
The Solaris operating system is still a part of the Sun Microsystems inventory and is no longer really up to date. Accordingly, Oracle’s wish to mark the ports for Solaris/SPARC, Solaris/x64 and Linux/SPARC as deprecated is not surprising. The next step, according to JEP 362, is to get rid of them in a future update. However, it should be noted that old Java versions (up to JDK 14) should run unchanged on old systems, including the corresponding ports.
The goal of the whole thing is to be able to take care of other features. However, if there is a group of dedicated and interested developers who want to maintain and administer the ports, the removal from the JDK could be overturned at a later date.
Helpful NullPointerExceptions
Improve the usability of NullPointerExceptions generated by the JVM by describing precisely which variable was null.
EXAMPLE
Suppose an NPE occurs in 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)
Using the message, which is typically included in a bug report, the developer can locate a.i = 99; and infer that a must have been null.
However, for more complex code, it is impossible to decide which variable was null without using a debugger. Suppose an NPE occurs in this code:
a.b.c.i = 99;
The filename and line number do not pinpoint exactly which variable was null. Was it a or b or c?
SOLUTION
If the more complex statement a.b.c.i = 99; throws an NPE, the message would dissect the statement and pinpoint the cause by showing the full access path which led up to the null:
Exception in thread "main" java.lang.NullPointerException:
Cannot read field "c" because "a.b" is null
at Prog.main(Prog.java:5)
NVM Feature
Java 14 adds new JDK-specific file mapping modes so that the FileChannel API can be used to create MappedByteBuffer instances that refer to non-volatile memory.
Let's understand that feature!
https://www.dhirubhai.net/pulse/understanding-java-14-nvm-feature-vincent-vauban/
#technology #java #java14 #jpackage #jep343 #jep345 #gc #garbagecollector #jep349 #javaflightrecorder #jfr #record #data #modeldataasdatainjava #switch #data #yield #jep362 #deprecatingsolarissparcport #jdk14 #feature #jep358 #npe #nvm #jep352 #mappedbytebuffer #filechannel #programming #javalanguageprogamming