Java 11, the latest version of Java programming language and Java Development Kit (JDK) is available now. Oracle just announced the release and download availability of Java SE 11, Java EE 11, Java SDK 11 and other related components.
Java SE 11 is available as a part of Java SDK 11 to download here.
Java is the most popular programming language in the world. The Java Platform, Standard Edition 11 Development Kit (JDK 11) is a feature release of the Java SE platform. It contains new features and enhancements in many functional areas.
Here is a list of some of the important changes in this release: 
  • The deployment stack, required for Applets and Web Start Applications, was deprecated in JDK 9 and has been removed in JDK 11. 
  • Without a deployment stack, the entire section of supported browsers has been removed from the list of supported configurations of JDK 11. 
  • Auto-update, which was available for JRE installations on Windows and macOS, is no longer available.
  • In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.
  • In this release, the JRE or Server JRE is no longer offered. Only the JDK is offered. Users can use jlink to create smaller custom runtimes.
  • JavaFX is no longer included in the JDK. It is now available as a separate download from
  • Java Mission Control, which was shipped in JDK 7, 8, 9, and 10, is no longer included with the Oracle JDK. It is now a separate download.
  • Previous releases were translated into English, Japanese, and Simplified Chinese as well as French, German, Italian, Korean, Portuguese (Brazilian), Spanish, and Swedish. However, in JDK 11 and later, French, German, Italian, Korean, Portuguese (Brazilian), Spanish, and Swedish translations are no longer provided.
  • Updated packaging format for Windows has changed from tar.gz to .zip, which is more common in Windows OSs.
  • Updated package format for macOS has changed from .app to .dmg, which is more in line with the standard for macOS.
What's New in JDK 11 - New Features and Enhancements
Here is a list of key new features and enhancements in this release.
APIs support version 10.0 of the Unicode Standard
The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions.
HTTP Client (Standard)
The HTTP Client has been standardized in Java 11. As part of this work the previously incubating API, located in the jdk.incubator.http package, has been removed. At a very minimum, code that uses types from the jdk.incubator.http package will need to be
New Collection.toArray(IntFunction) Default Method
A new default method toArray(IntFunction) has been added to the java.util.Collection interface. This method allows the collection's elements to be transferred to a newly created array of the desired runtime type. The new method is an overload of the existing toArray(T[]) method that takes an array instance as an argument. The addition of the overloaded method creates a minor source incompatibility. Previously, code of the form coll.toArray(null) would always resolve to the existing toArray method. With the new overloaded method, this code is now ambiguous and will result in a compile-time error. (This is only a source incompatibility. Existing binaries are unaffected.) The ambiguous code should be changed to cast null to the desired array type, for example, toArray((Object[])null) or some other array type. Note that passing null to either toArray method is specified to throw NullPointerException.
Updated Locale Data to Unicode CLDR v33
The locale data based on the Unicode Consortium's CLDR (Common Locale Data Registry) has been updated for JDK 11. Localized digits that are in supplementary planes (such as, those in Indian Chakma script) are substituted with ASCII digits until JDK-8204092 is resolved. Medium and short time patterns for Burmese locale have not been upgraded. When JDK-8209175 is resolved, these patterns will be upgraded.
Lazy Allocation of Compiler Threads
A new command line flag -XX:+UseDynamicNumberOfCompilerThreads has been added to dynamically control compiler threads. In tiered compilation mode, which is on by default, the VM starts a large number of compiler threads on systems with many CPUs regardless of the available memory and the number of compilation requests. Because the threads consume memory even when they are idle (which is almost all of the time), this leads to an inefficient use of resources.
To address this issue, the implementation has been changed to start only one compiler thread of each type during startup and to handle the start and shutdown of further threads dynamically. It is controlled by a new command line flag, which is on by default: 
  • ZGC A Scalable Low-Latency Garbage Collector (Experimental)
  • The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector (JEP 333). It is designed to meet the following goals:
  • Pause times do not exceed 10 ms
  • Pause times do not increase with the heap or live-set size
  • Handle heaps ranging from a few hundred megabytes to multi-terabytes in size
  • At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times.
  • ZGC is included as an experimental feature. To enable it, the -XX:+UnlockExperimentalVMOptions option will, therefore, need to be used in combination with the -XX:+UseZGC option. 
Epsilon, A No-Op Garbage Collector
Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short-lived jobs, where memory reclamation would happen at JVM termination or getting the last-drop latency improvements in low-garbage applications.
Low-Overhead Heap Profiling
Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI.
Nest-Based Access Control
Introduced nests, an access-control context that aligns with the existing notion of nested types in the Java programming language (JEP-181: Nest-based access control).
In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a nest. Nests allow classes and interfaces 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. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The javac compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new class files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a private constructor, method, or field, including via core reflection and the java.lang.invoke.MethodHandles.Lookup API. Membership in a nest is exposed through the new getNestHost and getNestMembers methods of java.lang.Class.
Key Agreement with Curve25519 and Curve448
JEP 324 adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation.
Added Brainpool EC Support (RFC 5639)
The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. The corresponding EC domain parameters can be created by using objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brain-pool curves.
ChaCha20 and Poly1305 Cryptographic Algorithms
Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher.
Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the Cipher.getInstance method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details.
Enhanced KeyStore Mechanisms
A new security property named jceks.key.serialFilter has been introduced. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by jdk.serialFilter is consulted.
If the system property jceks.key.serialFilter is also supplied, it supersedes the security property value defined here.
The filter pattern uses the same format as jdk.serialFilter. The default pattern allows java.lang.Enum,,$Type, and javax.crypto.spec.SecretKeySpec but rejects all the others.
Customers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable.
RSASSA-PSS Signature Support Added to SunMSCAPI
The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider.
Transport Layer Security (TLS) 1.3
The JDK 11 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.
Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009
The Kerberos 5 encryption types of aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192 defined in RFC 8009 are supported. These encryption types are enabled by default. The default order of preference is "aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5."
Users can use the default_tkt_enctypes and default_tgs_enctypes settings in the krb5.conf file to modify the list.
Local-Variable Syntax for Lambda Parameters
The reserved type name var can now be used when declaring the formal parameters of a lambda expression ([JEP 323]( This builds on the ability in Java SE 10 to use var when declaring local variables.
Using var for a formal parameter of a lambda expression causes the type of the parameter to be inferred, using the same rules as of when neither var nor an explicit type is present. Lambda expressions have allowed their formal parameters to be declared without explicit types since Java SE 8.
If var is used for any formal parameter of a lambda expression, then it must be used for all formal parameters of that lambda expression.
Launch Single-File Source-Code Programs
Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques.