Java JDK 11: All the new features now available

Java Development Kit (JDK) 11 is now generally available and ready for production use, bringing productivity improvements and an HTTP client API that implements HTTP/2.

Version 11 of Java Standard Edition (SE) has 16 major feature changes. Java 11 also loses some capabilities through the removal of CORBA and Java EE (recently renamed Jakarta EE) modules, as well as the removal of JavaFX, which is now available as a standalone technology.

In Java 11, Oracle has forked the mainline repository, jdk/jdk, to the jdk/jdk11 stabilization repository. Changes pushed to jdk/jdk or jdk/client are now marked for JDK 12. The stabilization repository can accept select bug fixes and, if approved, late enhancements as per the JDK Release Process.

The latest version of Oracle’s implementation of standard Java is a Long Term Support (LTS) release, which will have commercial support from Oracle for at least eight years. Bug fixes and security updates will be offered through 2026. New LTS releases are due every three years, with JDK 17, due in 2021, slated to be the next LTS release. Interim releases will come every six months.

Where to download JDK 11

You can download JDK 11 from the Oracle Technology Network.

New features in the Java 11 JDK

JDK 11 has 16 new features:

• Improving Aarch64 intrinsics, with the implementation of new intrinsics for the lang.Math sin, cos, and log functions, on Aarch64 processors. This proposal emphasizes specialized CPU architecture-specific code patterns that improve application and benchmark performance.
• Nest-based access control introduce nests, an access control context that aligns with the notion of nested types in the Java language. Nests allow classes that are logically part of the same code entity but are compiled to distinct class files to access each other’s private members without needing compilers to insert accessibility-broadening bridge methods.
• Transport Layer Security (TLS) 1.3, in which this overhaul of the TLS protocol will be fitted into JDK 11, offering significant security and performance benefits. There is no goal, however, to support every feature of TLS 1.3. To minimize risks of incompatibility, TLS 1.3 will implement backward-compatibility mode by default. Applications can turn this mode off or on as desired.
• Deprecation of the Nashorn JavaScript engine, along with the JJS tool, with the intent to remove them in the future. Oracle has found Nashorn challenging to maintain, given the rapid pace at which ECMAScript language constructs and APIs have been adapted and modified.
• HTTP Client (Standard), which standardizes the incubated HTTP API client introduced in JDK 9 and updated in JDK 10. The API offers nonblocking request and response semantics through CompleteableFutures, which can be linked to trigger dependent actions. The implementation, now asynchronous, has been almost completely rewritten, after incubating in JDKs 9 and 10. The RX Flow concept has been pushed into the implementation, eliminating many custom concepts needed to support HTTP/2. Data flow now can be more easily traced, from user-level request publishers and response publishers to the underlying socket. This reduces complexity and maximizes the possibility of reuse between HTTP/1 and HTTP/2.
• The Epsilon garbage collector, billed as a “no-op” collector, will handle memory allocation without implementing any actual memory reclamation mechanisms. Epsilon’s use cases include testing for performance, memory pressure, and the virtual machine interface. It also could be used for short-lived jobs.
• A local-variable syntax for lambda parameters should align the syntax of a formal parameter declaration in an implicitly typed expression with the syntax of a local variable declaration. This would allow var to be used when declaring formal parameters of a implicitly typed lambda expressions.
• The Java class-file format will be extended to support a new constant pool form, CONSTANT_Dynamic. The goal is to reduce the cost and disruption of developing new forms of materializable class-file constraints.
• Key agreement with Curve25519 and Curve448 cryptography should be more efficient and secure than the existing elliptic curve Diffie-Hellman scheme. The two elliptic curves, Curve25510 and Curve448, lend themselves to a constant-time implementation and an exception-free scalar multiplication that is more resistant to a range of side-channel attacks, including timing and cache attacks, according to the IETF. Goals of the proposal include an API and implementation of the key agreement scheme as well as development of a platform-independent, all-Java implementation. There is a risk, though, in the complexity and subtlety of the modular arithmetic implementation featured as part of the proposal.
• Flight Recorder would provide a low-overhead data collection framework for troubleshooting both Java applications and the HotSpot JVM. Flight Recorder has been a feature of Oracle’s commercial JDK, but would have its source code move to an open repository to make the feature generally available. Iclouded would be the APIs to produce and consume data as events, providing a buffer mechanism and binary data format and enabling configuration and filtering of events. The proposal also calls for providing events for the OS, HotSpot, and JDK libraries.
• Upgrading the platform APIs to support Unicode Version 10.0, thus keeping Java up to date. Support is expected in the following classes:
• Character andString in the lang package
• NumericShaper in the awt.font package
• Bidi, BreakIterator, and Normalizer in the text package
• Implementing the ChaCha20 and Poly1305 cryptographic algorithms. ChaCha2020 is a relatively new stream cipher that can replace the older, insecure R4 stream cipher. ChaCha20 would be paired with the Poly1305 authenticator. ChaCha20 and ChaCha20-Poly1305 cipher implementations would be provided, with the algorithms implemented in the SunJCE (Java Cryptography Extension) provider, using the crypto.CipherSpi API.
• Enhancing the Java launcher to run a program supplied as a single file of Java source code, so these programs can run directly from source. Single-file programs are common when writing small utilities or for developers in the early stages of learning Java. Also, a single source file might compile to multiple class files, which adds packaging overhead. In these contexts, having to compile a program before running it is just an unneeded step based on tradition.
• Low-overhead heap profiling, providing a way to sample Java heap allocations, accessible via JVM Tool Interface. The goal of this effort is to get information about these allocations in a manner that is low-overhead, can be accessed via a programmatic interface, and can sample all allocations. Implementation independence and provision of data about live and dead heaps are goals as well. Poor heap management can lead to heap exhaustion and garbage-collection thrashing. Most tools that address this lack the call site for particular allocations, information that can be critical to debugging memory issues.
• Deprecation of Pack200 and Unpack200 tools and the Pack200 API in util.jar. Pack200 is a compression scheme for .jar files, intended to decrease disk and bandwidth requirements for application packaging, transmission, and delivery. The maintenance costs and low usage don’t justify their retention, project leaders say.
• The Z Garbage Collector (ZGC), an experimental, low-latency garbage collector, to handle heaps ranging from relatively small  to very large heaps that are many terabytes in size. By using ZGC, pause times should not exceed 10ms and there should be no more than 15 percent application throughput reduction compared to using the G1 collector. ZGC also lays a foundation for future features and optimizations. Linux/x64 will be the first platform to get ZGC support.

What’s removed from Java JDK 11

The Java EE EE and CORBA modules were deprecated in Java SE 9, with the intent to remove them in a later release—which is JDK 11.

Java SE 6, released in December 2006, had included a full web services stack for the convenience of developers—including four technologies built for the Java EE platform: JAX-WS (Java API for XML-based Web Services,  JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework), and Common Annotations for Java. Over time, the Java EE versions evolved, leading to difficulties in the Java SE, such as including technologies irrelevant to Java SE and more difficult maintenance across the two Java editions. With standalone versions of the Java EE technologies available from third-party sites, Oracle says there is no longer a need to have them in Java SE or in the JDK.

Still, some applications will not compile or run if they rely on out-of-the-box support in the JDK for Java EE APIs and tools. Binary and source incompatibilities would arise when migrating JDK 6, 7, or 8 to a later release. Oracle says that developers affected by these risks can deploy alternate versions of Java EE technologies instead.

CORBA dates back to the 1990s, and Oracle says that today there is no significant interest in developing modern Java applications with CORBA. And the costs of maintaining CORBA support outweigh its remaining benefits.

But the removal of CORBA risks having CORBA implementations that will not run if they include only a subset of CORBA APIs and expect the JDK to provide the remainder. There is no third-party CORBA version, and it is uncertain if a third party could take over CORBA API maintenance.

JavaFX is being removed so it is not tied to Java JDK’s twice-annual update schedule.