Are you ready for Java 11?

‘Java 11’ is now just around the corner. Officially it is scheduled to release on September 25th. Hence its right time now to find out what does this new release has in its offering. In this article, we’ll take a quick look at the new features which will be available to us from this release.

Before we dive into the features, here is the release schedule published by oracle.

Schedule

2018/06/28		Rampdown Phase One (fork from main line) >> We are here
2018/07/19		All Tests Run
2018/07/26		Rampdown Phase Two
2018/08/16		Initial Release Candidate
2018/08/30		Final Release Candidate
2018/09/25		General Availability

At the time of writing this article, JDK11 is in Rampdown phase one which means that overall feature set is frozen and no further JEPs will be targeted to this release.

Features

In total there are 17 JEP’s targeted for this release. For our better understanding let's divide these JEP’s/features into 5 categories

1.     Language and API

a.    JEP 323: Local-Variable Syntax for Lambda Parameters

b.    JEP 321: HTTP Client (Standard)

c.    JEP 327: Unicode 10

d.    JEP 320: Remove the Java EE and CORBA Modules

2.     Security

a.    JEP 324: Key Agreement with Curve25519 and Curve448

b.    JEP 329: ChaCha20 and Poly1305 Cryptographic 

c.    JEP 332: Transport Layer Security (TLS) 1.3

3.     Tools

a.    JEP 318: Epsilon: A No-Op Garbage Collector

b.    JEP 328: Flight Recorder

c.    JEP 330: Launch Single-File Source-Code Programs

d.    JEP 331: Low-Overhead Heap Profiling

e.    JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

4.     Low level -  These changes relate to how JVM works and very unlikely going to affect developers directly

a.    JEP 181: Nest-Based Access Control

b.    JEP 309: Dynamic Class-File Constants

c.    JEP 315: Improve Aarch64 Intrinsics

5.     Deprecations

a.    JEP 335: Deprecate the Nashorn JavaScript Engine

b.    JEP 336: Deprecate the Pack200 Tools and API

Without going into too much of depth here I am going to briefly explain the feature/changes these JEP’s going to offer us so that we get ourselves familiar with all new changes getting released with Java 11.

I will be writing subsequent articles wherein I will explain these changes in more detail which will include the motivation behind the change, how change going to impact us as a developer etc and each article will only target changes included in a particular JEP.

Okay so without wasting any more time let’s try to understand what these changes are:

JEP 323: Local-Variable Syntax for Lambda Parameters

This JEP will allow keyword var (introduced in Java 10) to be used when declaring the formal parameters of implicitly typed lambda expressions. 

Goal here is to align the syntax of a formal parameter declaration in an implicitly typed lambda expression with the syntax of a local variable declaration.

A lambda expression may be implicitly typed, where the types of all its formal parameters are inferred:

For example: Implicitly typed lambda expression, 

(x, y) -> x.test(y)     

Java SE 10 makes implicit typing available for local variables:

var x = new Car();

for (var x : list) { ... }

Note: Want to read more about how this beautiful addition of 'var' in Java language affects us as a developer? Read about it at here

In order to have uniformity with local variables, this JEP will allow 'var' for the formal parameters of an implicitly typed lambda expression:

(var x, var y) -> x.test(y) // implicit typed lambda expression

             (var x, var y) -> x.test(y)

              is equivalent to:

             (x, y) -> x.test(y)

One benefit of uniformity is that annotations can be applied to local variables and lambda formals in exactly same way:

// local variable declaration

@Nonnull var x = new Foo(); 

// implicit typed lambda

(@Nonnull var x, @Nullable var y) -> x.test(y)  

JEP 321: HTTP Client (Standard)

This JEP aims at

• Standardizing the incubated HTTP Client API introduced in JDK 9, via JEP 110, and which got updated in JDK 10.
• Standardized API will be provided in the java.net.http package which will be based upon the incubated API, and
• Remove the incubated API

Important feature of new standard API is that,

• Implementation is now completely asynchronous, it provides non-blocking request and response semantics through CompletableFutures (the previous HTTP/1.1 implementation was blocking).
• RX Flow concept has been added into the implementation, which eliminated many of the original custom concepts needed to support HTTP/2.

JEP 327: Unicode 10

This JEP aims at upgrading existing Java platform APIs to support version 10.0 of the Unicode Standard. There will be updates to the platform to ensure support with Unicode 10, which adds 8,518 characters, 56 of which are new emojis and yes there is an entry for bitcoin sign as well.

JEP 320: Remove the Java EE and CORBA Modules

This JEP aims to remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release. Rather than hanging onto them for long, they are now gone!

JEP 324: Key Agreement with Curve25519 and Curve448

This JEP is for implementation of key agreement using Curve25519 and Curve448 as per RFC 7748. RFC 7748 defines a key agreement scheme that is more efficient and secure than the existing elliptic curve Diffie-Hellman (ECDH) scheme. The primary goal of this JEP is an API and an implementation for this standard.

Motivation comes from the fact that cryptography using Curve25519 and Curve448 is in demand due to their excellent security and performance properties. Key exchange using these curves is already supported in many other cryptographic libraries for example OpenSSL.

JEP 329: ChaCha20 and Poly1305 Cryptographic

This JEP is for implementation of ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. Motivation behind this implementation it that the only other widely adopted stream cipher, RC4, has long been deemed insecure. The industry consensus is that ChaCha20-Poly1305 is secure at this point in time, and it has seen fairly wide adoption across TLS implementations as well as in other cryptographic protocols. This implementation will help JDK remain on par with other cryptographic toolkits and TLS implementations.

JEP 332: Transport Layer Security (TLS) 1.3

This JEP is for implementing version 1.3 of the Transport Layer Security (TLS) Protocol which provides significant security and performance improvements over previous versions. There will be no new public APIs required for the minimal implementation of TLS 1.3 in Java Secure Socket Extension (JSSE) framework. This implementation will help java platform remain up to date, remain competitive and keep pace with the latest standard.

JEP 318: Epsilon: A No-Op Garbage Collector

This JEP aims to develop a garbage collector that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down. Strange, isn’t it? Why would we want this if this GC is not doing any GC?  That’s a good question. Performance testing, memory pressure testing are some of the use cases wherein this No-op GC could be useful.

One more point, this is completely new GC implementation and it doesn’t touch any of existing other GCs.

JEP 328: Flight Recorder

Instead of going for third-party tools this JEP aims to provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM.

Flight Recorder will record events originating from applications, the JVM and the OS. Events will be stored in a single file that can be attached to bug reports and examined by support engineers to find root cause of the problem.

JEP 330: Launch Single-File Source-Code Programs

This will be an excellent feature for the beginners who are trying to learn java language. This JEP aims to enhance the java launcher to run a program supplied as a single file of Java source code. So instead of compiling the src file, generating the class file and then running the program using class file directly src file can be used to run the program. Only condition is that all the source code should be available in that single file.

Essentially instead of executing java program using ‘java HelloWorld’ below can be used

 >java HelloWorld.java

JEP 331: Low-Overhead Heap Profiling

Profiling is an important area and crucial too in order to fix performance and memory issues within the application. Using profiling tools and techniques we can figure out what is going on the heap.

There are already number of tools that have been developed to allow users to introspect into their heaps, such as jmap, YourKit, and VisualVM but most tools lack providing call site for particular allocations (i.e., information about the exact location in developer’s code where particular memory allocations occurred).

This JEP aims to provide a low-overhead way to get information about Java object heap allocations from the JVM which would include call site information as well. This information is critical to debug memory issues and having this information handy would help in the debug process.

JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector. This is an experimental garbage collection that reduces the length of GC pauses. Note that this feature will only work on Linux/x64 for the moment. Support for additional platforms can be added later, if there is enough demand. If this GC meets its goals then this could be a huge boost to Java application performance.

JEP 181: Nest-Based Access Control

In java classes can be nested and nested classes can access each other’s private data. But to let this happen compiler does extra work. It creates something called “access bridges” in order to allow this happen.

This JEP introduces “Nests - an access-control context”. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods. Essentially this will simplify the job of Java source code compilers.

JEP 309: Dynamic Class-File Constants

This JEP aims to extend the Java class-file format to support a new constant-pool form, CONSTANT_Dynamic.

Idea is to support arbitrary constants in the constant pool and essentially reduce cost and disruption of creating new forms of class-file constants. This will be achieved by creating a single new constant-pool form (CONSTANT_Dynamic) that can be parameterized with user-provided behavior, in the form of a bootstrap method with static arguments.

Don’t bother if you don’t understand any of above explanation. This feature is mostly for language designers and for those who implement compilers. You as a developer never going to use it.

JEP 315: Improve Aarch64 Intrinsics

This will provide performance improvements for string and arrays, as well as standard Math.sin, cos and log functions. Optimized Intrinsics will be implemented to leverage CPU architecture-specific assembly code which is executed instead of generic Java code for a given method to improve performance. 

Again, all this changes are under the hood and at JVM level. So developers will continue to use methods as they use today and experience the performance gains.

JEP 335: Deprecate the Nashorn JavaScript Engine

This JEP aims to deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release. Nashorn JavaScript engine was first incorporated into JDK 8 as a replacement for the Rhino scripting engine. At the time of release, it was a complete implementation of the ECMAScript-262 5.1 standard.

It’s understandably difficult to maintain Nashorn with the pace of changes in ECMAScript which has resulted in submission of this JEP to deprecate this engine. On lighter note does anyone really uses it? Better to let it go!

JEP 336: Deprecate the Pack200 Tools and API

This JEP aims to deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.

Pack200 is a compression scheme for JAR files. It was introduced in Java SE 5.0 Developers use a pair of tools -- pack200 and unpack200 -- to compress and uncompress their JAR files. An API is available in the java.util.jar package.

Reason for wanting to deprecate (and eventually remove) Pack200 is that major consumer of Pack200 -- the JDK itself -- no longer needs it since it uses new compression schemes for both the Java runtime and the modules used to build the runtime.

How to try out and play with Java 11 features?
Firstly we will need to install JDK 11 on our machine. For that we need to download it from early access builds page (http://jdk.java.net/11/). Choose the appropriate OS and download either OpenJDK build or Oracle JDK build.
Once downloaded install it on your system. It’s likely that IDE may not support JDK 11 just yet, eclipse photon doesn't yet support it but IntelliJ idea latest update might be supporting it. Please check it out or else you may need to get your hands dirty using command prompt or use JShell for playing around.