The following APIs were removed in JDK 11. Many of these APIs were deprecated in previous releases and have been replaced by newer APIs. For information on the possible alternatives, see JDK 11 API Specification.

javax.security.auth.Policy 
java.lang.Runtime.runFinalizersOnExit(boolean)
java.lang.SecurityManager.checkAwtEventQueueAccess() 
java.lang.SecurityManager.checkMemberAccess(java.lang.Class,int)
java.lang.SecurityManager.checkSystemClipboardAccess()
java.lang.SecurityManager.checkTopLevelWindow(java.lang.Object)
java.lang.System.runFinalizersOnExit(boolean)
java.lang.Thread.destroy()
java.lang.Thread.stop(java.lang.Throwable)

If you must use an internal API that has been made inaccessible by default, then you can break encapsulation using the --add-exports command-line option.

--add-exports <source-module>/<package>=<target-module>(,<target-module>)*

The --add-exports option allows code in the target module to access types in the named package of the source module if the target module reads the source module.

--add-exports java.management/sun.management=ALL-UNNAMED

--add-exports java.management/com.sun.jmx.remote.internal=ALL-UNNAMED

Add-Exports:java.management/sun.management

Use the --add-exports option carefully. You can use it to gain access to an internal API of a library module, or even of the JDK itself, but you do so at your own risk. If that internal API changes or is removed, then your library or application fails.

See also JEP 261.

If you have to allow code on the class path to do deep reflection to access nonpublic members, then use the --add-opens runtime option.

Some libraries do deep reflection, meaning setAccessible(true), so they can access all members, including private ones. You can grant this access using the --add-opens option on the java command line. No warning messages are generated as a result of using this option.

If --illegal-access=deny, and you see IllegalAccessException or InaccessibleObjectException messages at runtime, you could use the --add-opens runtime option, basing the arguments upon the information shown in the exception message.

--add-opens module/package=target-module(,target-module)*

--add-opens java.management/sun.management=ALL-UNNAMED

<j2se version="10" java-vm-args="--add-opens=module/package=ALL-UNNAMED"  />

After you install the JDK, if you look at the file system, you’ll notice that the directory layout is different from that of releases before JDK 9.

JDK 11

JDK 11 does not have the JRE image. See Installed Directory Structure of JDK in Java Platform, Standard Edition Installation Guide.

JDK 9 and JDK 10

Prior releases produced two types of runtime images: the JRE, which was a complete implementation of the Java SE Platform, and the JDK, which included the entire JRE in a jre/ directory, plus development tools and libraries.

In JDK 9 and and JDK 10, the JDK and JRE are two types of modular runtime images, where each contains the following directories:

• bin: contains binary executables.

• conf: contains .properties, .policy, and other kinds of files intended to be edited by developers, deployers, and end users. These files were formerly found in the lib directory or its subdirectories.

• lib: contains dynamically linked libraries and the complete internal implementation of the JDK.

In JDK 9 and JDK 10, there are still separate JDK and JRE downloads, but each has the same directory structure. The JDK image contains the extra tools and libraries that have historically been found in the JDK. There are no jdk/ versus jre/ wrapper directories, and binaries (such as the java command) aren’t duplicated.

See JEP 220: Modular Run-Time Images.

JDK 9 and later releases maintain the hierarchy of class loaders that existed since the 1.2 release. However, the following changes have been made to implement the module system:

• The application class loader is no longer an instance of URLClassLoader but, rather, of an internal class. It is the default loader for classes in modules that are neither Java SE nor JDK modules.

• The extension class loader has been renamed; it is now the platform class loader. All classes in the Java SE Platform are guaranteed to be visible through the platform class loader.

  Just because a class is visible through the platform class loader does not mean the class is actually defined by the platform class loader. Some classes in the Java SE Platform are defined by the platform class loader while others are defined by the bootstrap class loader. Applications should not depend on which class loader defines which platform class.

  The changes that were implemented in JDK 9 may impact code that creates class loaders with null (that is, the bootstrap class loader) as the parent class loader and assumes that all platform classes are visible to the parent. Such code may need to be changed to use the platform class loader as the parent (see ClassLoader.getPlatformClassLoader).

  The platform class loader is not an instance of URLClassLoader, but, rather, of an internal class.

• The bootstrap class loader is still built-in to the Java Virtual Machine and represented by null in the ClassLoader API. It defines the classes in a handful of critical modules, such as java.base. As a result, it defines far fewer classes than in JDK 8, so applications that are deployed with -Xbootclasspath/a or that create class loaders with null as the parent may need to change as described previously.

Class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar and various other internal JAR files are stored in a more efficient format in implementation-specific files in the lib directory.

The removal of rt.jar and similar files leads to issues in these areas:

• Starting from JDK 9, ClassLoader.getSystemResource doesn’t return a URL pointing to a JAR file (because there are no JAR files). Instead, it returns a jrt URL, which names the modules, classes, and resources stored in a runtime image without revealing the internal structure or format of the image.

  For example:

  ClassLoader.getSystemResource("java/lang/Class.class");

  When run on JDK 8, this method returns a JAR URL of the form:

  jar:file:/usr/local/jdk8/jre/lib/rt.jar!/java/lang/Class.class

  which embeds a file URL to name the actual JAR file within the runtime image.

  A modular image doesn’t contain any JAR files, so URLs of this form make no sense. On JDK 9 and later releases, this method returns:

  jrt:/java.base/java/lang/Class.class

• The java.security.CodeSource API and security policy files use URLs to name the locations of code bases that are to be granted specific permissions. See Policy File Syntax in Java Platform, Standard Edition Security Developer's Guide. Components of the runtime system that require specific permissions are currently identified in the conf/security/java.policy file by using file URLs.

• Older versions of IDEs and other development tools require the ability to enumerate the class and resource files stored in a runtime image, and to read their contents directly by opening and reading rt.jar and similar files. This isn’t possible with a modular image.

In JDK 8 and earlier, the extension mechanism made it possible for the runtime environment to find and load extension classes without specifically naming them on the class path. Starting from JDK 9, if you need to use the extension classes, ensure that the JAR files are on the class path.

In JDK 9 and JDK 10, the javac compiler and java launcher will exit if the java.ext.dirs system property is set, or if the lib/ext directory exists. To additionally check the platform-specific systemwide directory, specify the -XX:+CheckEndorsedAndExtDirs command-line option. This causes the same exit behavior to occur if the directory exists and isn’t empty. The extension class loader is retained in JDK 9 (and later releases) and is specified as the platform class loader (see getPlatformClassLoader.) However, in JDK 11, this option is obsolete and a warning is issued when it is used.

The following error means that your system is configured to use the extension mechanism:

<JAVA_HOME>/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead.
.Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

You’ll see a similar error if the java.ext.dirs system property is set.

To fix this error, remove the ext/ directory or the java.ext.dirs system property.

See JEP 220: Modular Run-Time Images.

The java.endorsed.dirs system property and the lib/endorsed directory are no longer present. The javac compiler and java launcher will exit if either one is detected.

Starting from JDK 9, you can use upgradeable modules or put the JAR files on the class path.

This mechanism was intended for application servers to override components used in the JDK. Packages to be updated would be placed into JAR files, and the system property java.endorsed.dirs would tell the Java runtime environment where to find them. If a value for this property wasn’t specified, then the default of $JAVA_HOME/lib/endorsed was used.

In JDK 8, you can use the -XX:+CheckEndorsedAndExtDirs command-line argument to check for such directories anywhere on the system.

In JDK 9 and later releases, the javac compiler and java launcher will exit if the java.endorsed.dirs system property is set, or if the lib/endorsed directory exists.

The following error means that your system is configured to use the endorsed standards override mechanism:

<JAVA_HOME>/lib/endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

You’ll see a similar error if the java.endorsed.dirs system property is set.

To fix this error, remove the lib/endorsed directory, or unset the java.endorsed.dirs system property.

See JEP 220: Modular Run-Time Images.

The Java 11 installer creates these Windows registry keys when installing the JDK:

• “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK”

• “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11”

If there are two versions of JDK installed, then there will be two different Windows registry keys are created. For example, if JDK 11.0.1 is installed with JDK 11, then the installer creates the another Windows registry key as shown:

• “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK”

• “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11.0.1”

The following are some important APIs that have been removed from JDK 9 and JDK 10 releases.

Starting in JDK 9, you can choose to build and run your application against any subset of the modules in the Java runtime image, without needing to rely on predefined profiles.

Profiles, introduced in Java SE 8, define subsets of the Java SE Platform API that can reduce the static size of the Java runtime on devices that have limited storage capacity. The tools in JDK 8 support three profiles, compact1, compact2, and compact3. For the API composition of each profile, see Detailed Profile Composition and API Reference in the JDK 8 documentation.

In JDK 8, you use the -profile option to specify the profile when running the javac and java commands. Starting in JDK 9, the -profile option is supported by javac only in conjunction with the --release 8 option, and isn’t supported by java.

JDK 9 and later releases let you choose the modules that are used at compile and run time. By specifying modules with the new --limit-modules option, you can obtain the same APIs that are in the compact profiles. This option is supported by both the javac and java commands, as shown in the following examples:

javac --limit-modules java.base,java.logging MyApp.java

java --limit-modules java.base,java.logging MyApp

You can use the jdeps tool to do a static analysis of the Java packages that are being used in your source code. This gives you the set of modules that you need to execute your application. If you had been using the compact3 profile, for example, then you may see that you don’t need to include that entire set of modules when you build your application. See jdeps in Java Platform, Standard Edition Tools Reference.

See JEP 200: The Modular JDK.

Starting in JDK 9, the Unicode Consortium's Common Locale Data Repository (CLDR) data is enabled as the default locale data, so that you can use standard locale data without any further action.

In JDK 8, although CLDR locale data is bundled with the JRE, it isn’t enabled by default.

Code that uses locale-sensitive services such as date, time, and number formatting may produce different results with the CLDR locale data. Remember that even System.out.printf() is locale-aware.

To enable behavior compatible with JDK 8, set the system property java.locale.providers to a value with COMPAT ahead of CLDR, for example, java.locale.providers=COMPAT,CLDR.

See CLDR Locale Data Enabled by Default in the Java Platform, Standard Edition Internationalization Guide and JEP 252: Use CLDR Locale Data by Default.

The ability to request a version of the JRE that isn’t the JRE being launched at launch time is removed, starting in JDK 9.

Modern applications are typically deployed using Java Web Start (JNLP), native OS packaging systems, or active installers. These technologies have their own methods to manage the JREs needed, by finding or downloading and updating the required JRE, as needed. This makes the launcher's launch-time JRE version selection obsolete.

In the previous releases, you could specify what JRE version (or range of versions) to use when starting an application. Version selection was possible through both a command-line option and manifest entry in the application's JAR file.

See JEP 231: Remove Launch-Time JRE Version Selection.

Starting in JDK 9, the ability to deploy an applet as a serialized object isn’t supported. With modern compression and JVM performance, there’s no benefit to deploying an applet in this way.

The object attribute of the applet tag and the object and java object applet parameter tags are ignored when starting applet.

Instead of serializing applets, use standard deployment strategies.

JNLP (Java Network Launch Protocol) has been updated to remove inconsistencies, make code maintenance easier, and enhance security.

JNLP has been updated as follows:

1. & instead of & in JNLP files.

   The JNLP file syntax conforms to the XML specification and all JNLP files should be able to be parsed by standard XML parsers.

   JNLP files let you specify complex comparisons. Previously, this was done by using the ampersand (&), but this isn’t supported in standard XML. If you’re using & to create complex comparisons, then replace it with & in your JNLP file. & is compatible with all versions of JNLP.

2. Comparing numeric version element types against nonnumeric version element types.

   Previously, when an int version element was compared with another version element that couldn’t be parsed as an int, the version elements were compared lexicographically by ASCII value.

   Starting in JDK 9, if the element that can be parsed as an int is a shorter string than the other element, it will be padded with leading zeros before being compared lexicographically by ASCII value. This ensures there can be no circularity.

   In the case where both version comparisons and a JNLP servlet are used, you should use only numeric values to represent versions.

3. Component extensions with nested resources in java (or j2se) elements.

   This is permitted in the specification. It was previously supported, but this support wasn’t reflected in the specification.

4. FX XML extension.

   The JNLP specification has been enhanced to add a type attribute to application-desc element, and add the subelement param in application-desc (as it already is in applet-desc).

   This doesn’t cause problems with existing applications because the previous way of specifying a JavaFX application is still supported.

See the JNLP specification updates at JSR-056.

If your application previously required the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files, then you no longer need to download or install them. They are included in the JDK and are activated by default.

If your country or usage requires a more restrictive policy, the limited Java cryptographic policy files are still available.

If you have requirements that are not met by either of the policy files provided by default, then you can customize these policy files to meet your needs.

See the crypto.policy Security property in the <java-home>/conf/security/java.security file, or Cryptographic Strength Configuration in the Java Platform, Standard Edition Security Developer's Guide.

You are advised to consult your export/import control counsel or attorney to determine the exact requirements.

We recommend that you use the PKCS12 format for your keystores. This format, which is the default keystore type, is based on the RSA PKCS12 Personal Information Exchange Syntax Standard.

See Creating a Keystore to Use with JSSE in Java Platform, Standard Edition Security Developer's Guide and keytool in Java Platform, Standard Edition Tools Reference.

The Garbage-First Garbage Collector (G1 GC) is the default garbage collector in JDK 9 and later releases.

A low-pause collector such as G1 GC should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is the JDK 8 default.

See Ergonomic Defaults for G1 GC and Tunable Defaults in Java Platform, Standard Edition Java Virtual Machine Guide for more information about tuning G1 GC.

The following GC combinations will cause your application to fail to start in JDK 9 and later releases:

The foreground mode for CMS has also been removed. The command-line flags that were removed are -Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction, and -XX:+UseCMSCollectionPassing.

The command-line flag -XX:+UseParNewGC no longer has an effect. The ParNew flag can be used only with CMS and CMS requires ParNew. Thus, the -XX:+UseParNewGC flag has been deprecated and is eligible for removal in a future release.

See JEP 214: Remove GC Combinations Deprecated in JDK 8.

Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0

Garbage collection (GC) logging uses the JVM unified logging framework, and there are some differences between the new and the old logs. Any GC log parsers that you’re working with will probably need to change.

You may also need to update your JVM logging options. All GC-related logging should use the gc tag (for example, —Xlog:gc), usually in combination with other tags. The —XX:+PrintGCDetails and -XX:+PrintGC options have been deprecated.

See Enable Logging with the JVM Unified Logging Framework in the Java Platform, Standard Edition Tools Reference and JEP 271: Unified GC Logging.

The javah tool has been superseded by superior functionality in javac. It was removed in JDK 10.

Since JDK 8, javac provides the ability to write native header files at the time that Java source code is compiled, thereby eliminating the need for a separate tool.

javac -h

JavaDB, which was a rebranding of Apache Derby, is no longer included in the JDK.

JavaDB was bundled with JDK 7 and JDK 8. It was found in the db directory of the JDK installation directory.

You can download and install Apache Derby from Apache Derby Downloads.

The hprof agent library has been removed.

The hprof agent was written as demonstration code for the JVM Tool Interface and wasn’t intended to be a production tool. The useful features of the hprof agent have been superseded by better alternatives, including some that are included in the JDK.

For creating heap dumps in the hprof format, use a diagnostic command (jcmd) or the jmap tool:

• Diagnostic command: jcmd <pid> GC.heap_dump. See jcmd.
• jmap: jmap -dump. See jmap.

For CPU profiler capabilities, use the Java Flight Recorder, which is bundled with the JDK.

See JEP 240: Remove the JVM TI hprof Agent.

The jhat tool was an experimental, unsupported heap visualization tool added in JDK 6. Superior heap visualizers and analyzers have been available for many years.

The launchers java-rmi.exe from Windows and java-rmi.cgi from Linux and Solaris have been removed.

java-rmi.cgi was in $JAVA_HOME/bin on Linux and Solaris.

java-rmi.exe was in $JAVA_HOME/bin on Windows.

These launchers were added to the JDK to facilitate use of the RMI CGI proxy mechanism, which was deprecated in JDK 8.

The alternative of using a servlet to proxy RMI over HTTP has been available, and even preferred, for several years. See Java RMI and Object Serialization.

The IIOP transport support from the JMX RMI Connector along with its supporting classes have been removed from the JDK.

In JDK 8, support for the IIOP transport was downgraded from required to optional. This was the first step in a multirelease effort to remove support for the IIOP transport from the JMX Remote API. In JDK 9, support for IIOP was removed completely.

Public API changes include:

• The javax.management.remote.rmi.RMIIIOPServerImpl class has been deprecated. Upon invocation, all its methods and constructors throw java.lang.UnsupportedOperationException with an explanatory message.

• Two classes, org.omg.stub.javax.management.rmi._RMIConnection_Stub, and org.omg.stub.javax.management.rmi._RMIConnection_Tie, aren’t generated.

The Windows 32–bit client VM is no longer available. Only a server VM is offered.

JDK 8 and earlier releases offered both a client JVM and a server JVM for Windows 32-bit systems. JDK 9 and later releases offer only a server JVM, which is tuned to maximize peak operating speed.

Java VisualVM is a tool that provides information about code running on a Java Virtual Machine. The jvisualvm tool was provided with JDK 6, JDK 7, and JDK 8.

Java VisualVM is no longer bundled with the JDK, but you can get it from the VisualVM open source project site.

The native2ascii tool has been removed from the JDK. Because JDK 9 and later releases support UTF-8 based properties resource bundles, the conversion tool for UTF-8 based properties resource bundles to ISO-8859-1 is no longer needed.

See UTF-8 Properties Files in Java Platform, Standard Edition Internationalization Guide.

The java.awt.Desktop class contains replacements for the APIs in the Apple–specific com.apple.eawt and com.apple.eio packages. The new APIs supersede the macOS APIs and are platform-independent.

The APIs in the com.apple.eawt and com.apple.eio packages are encapsulated, so you won’t be able to compile against them in JDK 9 or later releases. However, they remain accessible at runtime, so existing code that is compiled to old versions continues to run. Eventually, libraries or applications that use the internal classes in the apple and com.apple packages and their subpackages will need to migrate to the new API.

The com.apple.concurrent and apple.applescript packages are removed without any replacement.

See JEP 272: Platform-Specific Desktop Features.

The AppleScript engine, a platform-specific javax.script implementation, has been removed without any replacement in the JDK.

The AppleScript engine has been mostly unusable in recent releases. The functionality worked only in JDK 7 or JDK 8 on systems that already had Apple's version of the AppleScriptEngine.jar file on the system.