90 New Features and APIs in JDK 11 (Part 2)

The new six-month release cadence of the JDK means that before we’ve even really figured out what the new features are in JDK 10 along comes JDK 11. I posted an earlier blog where I listed all 109 new features and APIs I could find in JDK 10, so it seemed obvious to do the same thing for JDK 11. I’m going to use a different format from the previous post. In this series, I have divided everything into two sections: features that are visible to developers and everything else. This second installment focuses on everything else — from nest-based access control to garbage collectors and more.

Non-Developer Features

JEP 181: Nest-Based Access Control

Java (and other languages) supports nested classes through inner classes. To make this work correctly, it requires the compiler to perform some tricks. Here’s an example:

   public class Outer {
    private int outerInt;

     class Inner {
       public void printOuterInt() {
         System.out.println("Outer int = " + outerInt);
       }
     }
   }

The compiler modifies this to create something like this before performing compilation:

    public class Outer {
      private int outerInt;

      public int access$000() {
        return outerInt; 
      }

    }


    class Inner$Outer {

      Outer outer;

      public void printOuterInt() {
        System.out.println("Outer int = " + outer.access$000());
      }
    }

Although, logically, the inner class is part of the same code entity as the outer class, it is compiled as a separate class. It, therefore, requires a synthetic bridge method to be created by the compiler to provide access to the private field of the outer class.

This JEP introduces the concept of nests, where two members of the same nest (Outer and Inner from our example) are nestmates. Two new attributes are defined for the class file format, NestHost  and NestMembers. These changes are useful for other languages that support nested classes and are compiled to bytecodes.

This feature introduces three new methods to the  java.lang.Class:

•  getNestHost()
  
•  getNestMembers() 
  
• boolean isNestmateOf(Class) 

This feature also required changes to the Java Virtual Machine Specification (JVMS), specifically in section 5.4.4, Access Control.

JEP 309: Dynamic Class-File Constants

This JEP describes an extension to the class file format to support a new constant-pool form, CONSTANT_Dynamic  (often referred to in presentations as "condy"). The idea of a dynamic constant seems to be an oxymoron, but, essentially, you can think of it as a final value in Java. The constant-pool value is not set at compile-time (unlike the other constants) but uses a bootstrap method to determine the value at runtime. The value is, therefore, dynamic but, since its value is only set once, it is also constant.

This feature is primarily aimed at people developing new languages and compilers that will generate bytecodes and class files as an output to be run on the JVM. It simplifies some of the tasks required for this.

This feature introduces a new class,  java.lang.invoke.ConstantBootstraps, with nine new methods. I won’t list them all here; these are the bootstrap methods for dynamically computed constants.

This feature required changes to the JVMS, specifically in the areas of how the invokespecial bytecode is used and section 4.4, The Constant Pool.

JEP 315: Improve Aarch64 Intrinsics

This was a JEP contributed by Red Hat. The JVM is now able to take advantage of more of the specialized instructions available in the Arm 64 instruction set. Specifically, this improves performance of the  sin(), cos(), and log() methods of the java.lang.Math class.

JEP 318: The Epsilon Garbage Collector

Red Hat also contributed this JEP. The Epsilon collector is somewhat unusual, in that it does not collect any garbage! It will allocate memory, as required when new objects are instantiated, but it does not reclaim any space occupied by unreferenced objects.

When you first look at this, you think what is the point of that? It turns out that there are two uses:

1. Primarily, this collector is designed to enable new GC algorithms to be evaluated in terms of their performance impact. The idea is to run a sample application with the Epsilon GC and generate a set of metrics. The new GC algorithm is turned on, and the same tests run and the metric results compared.
2. For very short-lived tasks (think serverless functions in the cloud) where you can guarantee that you will not exceed the memory allocated to the heap, this can improve performance by not having any overhead (including gathering statistics necessary to decide when to run the collector) on the application code.

If the heap space is exhausted, the JVM can be configured to fail in one of three ways:

1. A conventional OutOfMemoryError is thrown.
2. Perform a heap dump
3. Fail the JVM hard and optionally perform another task (like running a debugger).

JEP 324: Key Agreement With Curve25519 and Curve448

Cryptographic standards are continually changing and improving. In this case, the existing elliptic-curve Diffie-Hellman scheme is being replaced by Curve25519 and Curve448. This is the key agreement scheme defined by RFC-7748.

JEP 327: Unicode 10

The Java platform supports Unicode to enable all character sets to be processed. Since Unicode has been updated to version 10, the JDK has also been updated to support this revision to the standard.

I’m always intrigued to see what the Unicode maintainers find to include in new versions. Unicode 10 has 8,518 new symbols. This includes the Bitcoin symbol, the Nüshu character set (used by Chinese women to write poetry), as well as Soyombo and Zanabazar Square (which are characters used in historic Buddhist texts to write Sanskrit, Tibetan, and Mongolian). There are also more emojis, including the long-awaited (apparently) Colbert Emoji.

Remember that, since JDK 9, you can use UTF-8 in property files. This means any Unicode character can be used in a property file, including emojis or Nüshu.

JEP 328: Flight Recorder

Flight Recorder is a low-overhead data collection framework for the JVM. Prior to JDK 11, this was a commercial feature in the Oracle JDK binary. Now that Oracle is eliminating functional differences between the Oracle JDK and one built from OpenJDK source code, this feature has been contributed to the OpenJDK.

There are four parts to this:

• Provide APIs for producing and consuming data as events
• Provide a buffer mechanism and a binary data format
• Allow the configuration and filtering of events
• Provide events for the OS, the HotSpot JVM, and the JDK libraries

There are two new modules for this:  jdk.jfr and  jdk.management.jfr.

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

Similar to JEP 324, this is an updating of ciphers used by the JDK. In this case, implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher.

JEP 331: Low-Overhead Heap Profiling

Somewhat surprisingly, this is a JEP contributed by Google. This provides a way to get information about Java object heap allocations from the JVM that:

• Is low-overhead enough to be enabled by default continuously
• Is accessible via a well-defined, programmatic interface
• Can sample all allocations
• Can be defined in an implementation-independent way (i.e., not limited to a particular GC algorithm or VM implementation)
• Can give information about both live and dead Java objects.

JEP 332: Transport Layer Security (TLS) 1.3

TLS 1.3 (RFC 8446) is a major overhaul of the TLS protocol and provides significant security and performance improvements over previous versions. The JDK now supports this, although this does not extend to Datagram Transport Layer Security (DTLS).

JEP 333: ZGC a Scalable, Low Latency Garbage Collector

This is a new, experimental garbage collector designed for use with applications that require a large (multi-gigabyte) heap and low-latency. It uses a single generation heap (which is a bit unusual, given the accepted wisdom of the Weak Generational Hypothesis) and performs most (but not all) of the GC work concurrently with the application. It does this through the use of a read-barrier that intercepts each read to an object from the application and ensures that the reference returned is correct. This eliminates the issue of being able to relocate objects concurrently while application threads are running.

ZGC is region-based (like G1), NUMA aware, and compacting. It is not intended as a general-purpose collector.

If you want a genuinely pauseless collector with low-latency, I can heartily recommend C4 in our Zing JVM.

JEP 335: Deprecate the Nashorn Scripting Engine

Nashorn was introduced in JDK 8 as a higher-performing replacement to the Rhino Javascript engine. The intention is to remove Nashorn, along with the associated APIs and jjs tool from a future version of Java. When this happens has not been decided yet. The possibility of using the Graal VM as a replacement has been suggested but how that will work has not been evaluated.

JEP 336: Deprecate the Pack200 Tools and APIs

Pack200 is a compression scheme for JAR files introduced in Java SE 5.0. With the introduction of the JPMS in JDK 9, Pack200 is no longer used to compress the JDK itself. The pack200, unpack200 tools, and the Pack200 API in java.util.jar are now deprecated and may be removed in a future version of the JDK. When this will happen has not been specified.

Conclusion

JDK 11 is the next LTS release of the JDK (as defined by Oracle and being followed by everyone else). Although there are not a lot of developer-focused features, there’s a lot going on lower down in the JVM, laying the groundwork for future, more prominent features.

Our Zulu builds of JDK 11 can be found here and are completely free!

Is it time to start migrating your applications to JDK 11? Let us know in the comments below!