Java 11 Features

JEP 309: Dynamic Class-File Constants

The Java class-file format will be extended to support a new constant pool form, CONSTANT_Dynamic. The goal of this feature is to reduce the cost and disruption of developing new forms of materializable class-file constraints, by creating a single new constant-pool form that can be parameterized with user-provided behavior. this change will enhances performance

JEP 318: Epsilon: A No-Op Garbage Collector

Unlike the JVM GC which is responsible for allocating memory and releasing it, Epsilon only allocates memory. It allocates memory for the following things:

• Performance testing.
• Memory pressure testing.
• VM interface testing.
• Extremely short lived jobs.
• Last-drop latency improvements.
• Last-drop throughput improvements.

Now Elipson is good only for test environments. It will lead to OutOfMemoryError in production and crash the applications.

The benefit of Elipson is no memory clearance overhead. Hence it’ll give an accurate test result of performance and we can no longer GC for stopping it.

Lets move forward with an example

We’ll first need an application, which creates garbage:

This code creates one-megabyte-arrays in a loop. Since we repeat the loop 10240 times, it means we allocate 10 gigabytes of memory, which is probably higher than the available maximum heap size.

We also provided some helper prints to see when the application terminates.

To enable Epsilon GC, we need to pass the following VM arguments:

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

And when we run the application, we get the following error:

Starting pollution
Terminating due to java.lang.OutOfMemoryError: Java heap space

However, when we run the same application with the standard VM options, it completes fine:

Starting pollution
Terminating

JEP 320: Remove the Java EE and CORBA Modules

The modules were already deprecated in Java 9. They are now completely removed.

Following packages are removed: java.xml.ws, java.xml.bind, java.activation, java.xml.ws.annotation, java.corba, java.transaction, java.se.ee, jdk.xml.ws, jdk.xml.bind

JEP 328: Flight Recorder

Flight Recorder which earlier used to be a commercial add-on in Oracle JDK is now open sourced since Oracle JDK is itself not free anymore.

JFR (Java Flight Recorder) is a profiling tool used to gather diagnostics and profiling data from a running Java application.

Its performance overhead is negligible and that’s usually below 1%. Hence it can be used in production applications.

Diagnosing faulty apps with JFR might shorten resolution times significantly. An anomaly can be seen from its first emergence as it unfolds and, finally, until that point when it causes the application to die. Of course, not all of the issues are that severe. JFR collects data about the running threads, GC cycles, locks, sockets, memory usage, and a lot more.

this one used to be a proprietary feature of the Oracle JDK, and officially, it was only available for paying, Oracle customers. In practice, you could enable it with the -XX:+UnlockCommercialFeatures -XX:+FlightRecorder flags, and earlier JVMs wouldn’t enforce having a license key or anything else like that.

JEP 321: HTTP Client

Java 11 standardizes the Http CLient API.

The new API supports both HTTP/1.1 and HTTP/2. It is designed to improve the overall performance of sending requests by a client and receiving responses from the server. It also natively supports WebSockets.

Reading/Writing Strings to and from the Files

Java 11 strives to make reading and writing of String convenient.

It has introduced the following methods for reading and writing to/from the files:

readString()
writeString()

Following code showcases an example of this

Java String methods

Java 11 support some improvements of String class. Added few additional methods on string class here follows few of them

isBlank() – This instance method returns a boolean value. Empty Strings and Strings with only white spaces are treated as blank.

System.out.println(" ".isBlank()); //true

lines() - This method returns a string array which is a collection of all substrings split by lines.

String str = "JD\nJD\nJD"; 
System.out.println(str);
System.out.println(str.lines().collect(Collectors.toList()));//output is array contains three JD string

strip(), stripLeading(), stripTrailing()

strip() – Removes the white space from both, beginning and the end of string.

stripLeading() - Removes the white space from beginning

stripTrailing() - Removes the white space from end

String str = " JD "; 
System.out.print(str.strip());

repeat(int) - The repeat method simply repeats the string that many numbers of times as mentioned in the method in the form of an int.

String str = "=".repeat(2);
System.out.println(str); //prints ==

Local-Variable Syntax for Lambda Parameters

JEP 323, Local-Variable Syntax for Lambda Parameters is the only language feature release in Java 11. In Java 10, Local Variable Type Inference was introduced. Thus we could infer the type of the variable from the RHS

 var list = new ArrayList<String>();
 
 

JEP 323 allows var to be used to declare the formal parameters of an implicitly typed lambda expression.

We can now define :

(var s1, var s2) -> s1 + s2

This was possible in Java 8 too but got removed in Java 10. Now it’s back in Java 11 to keep things uniform.

But why is this needed when we can just skip the type in the lambda?

If you need to apply an annotation just as @Nullable, you cannot do that without defining the type.

Limitation of this feature – You must specify the type var on all parameters or none.

Things like the following are not possible:

(var s1, s2) -> s1 + s2 //no skipping allowed
(var s1, String y) -> s1 + y //no mixing allowed

var s1 -> s1 //not allowed. Need parentheses if you use var in lambda.

Nested Based Access Control

Before Java 11 this was possible:

public class Main {
 
    public void myPublic() {
    }
 
    private void myPrivate() {
    }
 
    class Nested {
 
        public void nestedPublic() {
            myPrivate();
        }
    }
}

private method of the main class is accessible from the above-nested class in the above manner. But if we use Java Reflection, it will give an IllegalStateException.

Method method = ob.getClass().getDeclaredMethod("myPrivate");
method.invoke(ob);

Java 11 nested access control addresses this concern in reflection.

java.lang.Class introduces three methods in the reflection API: getNestHost(), getNestMembers(), and isNestmateOf().