Chapter 2. Major differences between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11

Before you migrate your Java applications from Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11, you must understand the updates and changes in Red Hat build of OpenJDK 11. These updates and changes might require you to configure Red Hat build of OpenJDK 8 before you migrate your applications to Red Hat build of OpenJDK 11.

One of the major differences between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11 is the inclusion of a module system in Red Hat build of OpenJDK 11. If you want to migrate your Red Hat build of OpenJDK 8 applications to Red Hat build of OpenJDK 11, consider moving the application’s libraries and modules from the Red Hat build of OpenJDK 8 class path to the Red Hat build of OpenJDK 11 module class. This change can improve the class-loading capabilities of your application.

Red Hat build of OpenJDK 11 includes new features and enhancements that can improve the performance of your application, such as enhanced memory usage, improved startup speed, and increased container integration.

Note

Some features might differ between the Red Hat build of OpenJDK and other upstream or third-party versions of OpenJDK. For example, the Shenandoah garbage collector (GC) is available on all the Red Hat builds of OpenJDK, but this feature might not be available by default in other builds of OpenJDK.

2.1. Cryptography and security

Certain minor cryptography and security differences exist between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11. However, both Red Hat build of OpenJDK versions have many similar cryptography and security behaviors.

Red Hat builds of OpenJDK use system-wide certificates, and each build obtains its list of disabled cryptographic algorithms from a system’s global configuration settings. These settings are common to all the Red Hat supported Red Hat build of OpenJDK releases, so you can easily change from Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11.

In FIPS mode, Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11 releases are self-configured, so that either release uses the same security providers at startup.

The TLS stacks in Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11 are similar, because the SunJSSE engine from Red Hat build of OpenJDK 11 was backported to Red Hat build of OpenJDK 8. Both Red Hat build of OpenJDK versions support the TLS 1.3 protocol.

The following minor cryptography and security differences exist between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11:

  • Red Hat build of OpenJDK 8 disabled the client-side TLSv1.3 by default, so an Red Hat build of OpenJDK 8 TLS client does not use the TLSv1.3 protocol during the communication process with the target server. You can use the jdk.tls.client.protocols system property to change this behavior by setting the -Djdk.tls.client.protocols=TLSv1.3 property for Red Hat build of OpenJDK 11.
  • Red Hat build of OpenJDK 11 supports the use of the X25519 and X448 EC curves in the Diffie-Hellman key exchange. This support is not available in Red Hat build of OpenJDK 8.
  • Red Hat build of OpenJDK 11 does not support the legacy KRB5-based cipher suites. Red Hat build of OpenJDK 8 still supports the legacy KRB5-based cipher suites, but you must enable these cipher suites by changing the jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system properties.
  • Red Hat build of OpenJDK 11 supports the Datagram Transport Layer Security (DTLS) protocol, so TLS clients and servers can use the max_fragment_length extension for DTLS. Red Hat build of OpenJDK 8 does not support this protocol.

2.2. Garbage collector (GC)

Red Hat build of OpenJDK 8 uses the Parallel GC as its default garbage collector, while Red Hat build of OpenJDK 11 uses the G1 GC as its default garbage collector. Before you choose a garbage collector consider the following details:

  • Use the Parallel GC if you want to improve throughput. The Parallel GC maximizes throughput, but at the expense of occasional pauses for stop-the-world collections.
  • Use the G1 GC for a balance between throughput and latency. This GC can perform latencies with pause times in the 100 ms range. If you notice throughput issues when migrating applications from the Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11, you can switch to the Parallel GC.
  • Use the Shenandoah GC for low latency collection.

You can select the GC type by using the -XX:+<gc_type> JVM option, such as -XX:+UseParallelGC to switch to the Parallel GC.

2.3. Garbage collector (GC) logging options

Red Hat build of OpenJDK 11 includes a new logging framework that works more effectively when compared to the old logging framework. Red Hat build of OpenJDK 11 also includes unified JVM logging options and unified GC logging options.

The logging system for Red Hat build of OpenJDK 11 activates the -XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps options by default. Because the logging format in Red Hat build of OpenJDK 11 is different from Red Hat build of OpenJDK 8, you might need to update any of your code that parses GC logs.

You can still access the old logging framework options in Red Hat build of OpenJDK 11 through aliases of the new framework options. If you want to work more effectively with Red Hat build of OpenJDK 11, use the new logging framework options.

Red Hat build of OpenJDK 11 replaced or removed the following Red Hat build of OpenJDK 8 options from the logging framework:

Options in Red Hat build of OpenJDK 8Options in Red Hat build of OpenJDK 11

-verbose:gc

-Xlog:gc

-XX:+PrintGC

-Xlog:gc

-XX:+PrintGCDetails

-Xlog:gc*

-Xloggc

-Xlog:gc:file=<path_to_filename>

When using the -XX:+PrintGCDetails option, pass the -Xlog:gc* flag.The * activates more detailed logging.

When using -Xloggc, append the :file=<filename> option to redirect log output to the specified file. For example -Xlog:gc:file=<filename>.

Note

If you specify an old tag option on the Java HotSpot VM, the VM prompts you with an available newer tag option. You can choose to use either the old or new tag option.

Red Hat build of OpenJDK 11 does not include the following options. If you attempt to use any of the options in Red Hat build of OpenJDK 11, you will receive startup errors.

  • -Xincgc
  • -XX:+CMSIncrementalMode
  • -XX:+UseCMSCompactAtFullCollection
  • -XX:+CMSFullGCsBeforeCompaction
  • -XX:+UseCMSCollectionPassing
Note

If you want to use any of the previously listed options in Red Hat build of OpenJDK 11, you can ignore any startup issues by issuing the -XX:+IgnoreUnrecognizedVMOptions option in your command-line interface.

Additional resources

2.4. OpenJDK graphics

Red Hat build of OpenJDK 11 uses Marlin as its default rendering engine, as opposed to Pisces in Red Hat build of OpenJDK 8. The Marlin rendering engine improves the handling of intensive application graphics.

The Marlin engine is available in Red Hat build of OpenJDK 8 and you can enable the Marlin engine by issuing -Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine for the Java runtime.

2.5. Webstart and applets

You can use Java WebStart with Red Hat build of OpenJDK 8 on RHEL 7, RHEL 8 and Microsoft Windows operating systems by using the IcedTea-Web plug-in. Red Hat build of OpenJDK 11 and later versions of Red Hat build of OpenJDK do not support Java Webstart.

Applets are not supported on Red Hat build of OpenJDK.

2.6. Java library classes

The Java Platform Module System (JPMS), which was introduced in Red Hat build of OpenJDK 9, limits or prevents access to non-public APIs. JPMS also impacts how you can start and compile your Java application, such as using a class path or using a module path.

By default, Red Hat build of OpenJDK 11 restricts access to JDK internal modules. As a workaround for this restriction when porting applications, you can provide access to an internal package for your application by passing options to the java command. These options are demonstrated in the following examples:

--add-opens <module-name>/<package-in-module>=ALL-UNNAMED

--add-opens java.base/jdk.internal.math=ALL-UNNAMED
Note

The previous workaround will not work indefinitely, because of the update behavior of Red Hat build of OpenJDK release cycles. A future release of Red Hat build of OpenJDK will close this workaround route.

Additionally, you can check illegal access cases by passing the --illegal-access=warn option to the java command. This option changes the default behavior of the Red Hat build of OpenJDK.

The JPMS refactoring changes the ClassLoader hierarchy in Red Hat build of OpenJDK 11. Red Hat build of OpenJDK 11 sets the system class loader to internal classes, so Java programs cannot access the system class loader.

For example, existing Red Hat build of OpenJDK 11 application code that invokes ClassLoader::getSystemClassLoader and casts the result to a URLClassLoader on Red Hat build of OpenJDK 11 might not work, because URLClassLoader is not part of the system class loader. If you attempt to cast a result to a URLClassLoader on Red Hat build of OpenJDK 11, you might receive a runtime exception message.

Red Hat build of OpenJDK 11 includes a new class loader that can control the loading of certain classes. This improves the way that a class loader can locate all of its required classes.

When you create a class loader, you can no longer pass null as its parent. If you do this in Red Hat build of OpenJDK 11, no class loader is selected as its parent, and your new class loader fails to locate platform classes. You can retrieve an instance of the platform class loader by using the ClassLoader.getPlatformClassLoader() API.

Additional resources

2.7. Extension and endorsed override mechanisms

In Red Hat build of OpenJDK 11, the extension mechanism, which supported optional packages, is no longer available. Red Hat build of OpenJDK 11 also removed the endorsed standards override mechanism.

You cannot use the libraries added to <JAVA_HOME>/lib/ext or <JAVA_HOME>/lib/endorsed. Red Hat build of OpenJDK 11 generates an error if it detects these directories. If you want to use optional packages on Red Hat build of OpenJDK 11, you can create a module for your optional package with the jlink tool, and then use the tool to include a custom runtime in your created module.

Additional resources

2.8. Deprecated and removed functionality from OpenJDK 11

Some features supported by Red Hat build of OpenJDK 8 have been either deprecated or removed in Red Hat build of OpenJDK 11.

COBRA

Red Hat build of OpenJDK 11 does not support the following tools:

  • Idlj
  • orbd
  • servertool
  • tnamesrv
Logging framework

Red Hat build of OpenJDK 11 does not support the following APIs:

  • java.util.logging.LogManager.addPropertyChangeListener
  • java.util.logging.LogManager.removePropertyChangeListener
  • java.util.jar.Pack200.Packer.addPropertyChangeListener
  • java.util.jar.Pack200.Packer.removePropertyChangeListener
  • java.util.jar.Pack200.Unpacker.addPropertyChangeListener
  • java.util.jar.Pack200.Unpacker.removePropertyChangeListener
Java EE modules

Red Hat build of OpenJDK 11 does not support the following APIs:

  • java.activation
  • java.corba
  • java.se.ee (aggregator)
  • java.transaction
  • java.xml.bind
  • java.xml.ws
  • java.xml.ws.annotation
Note

External dependencies might provide some of the previously listed APIs, so consider using these APIs if they were provided by dependencies.

java.awt.peer

Red Hat build of OpenJDK 11 sets the java.awt.peer package as internal. This means that applications cannot automatically access the package by default. Because of this change, Red Hat build of OpenJDK 11 removed classes and methods that refer to the peer API, such as the Component.getPeer method.

An example use case is using the peer API to check the following criteria:

  • A component can be displayed
  • The component is a lightweight component.
  • The component is backed by an OS native UI component.

This code can be updated with calls to Component.isDisplayable() and Component.isLightweight() to perform the same task.

javax.security and java.lang APIs

Red Hat build of OpenJDK 11 does not support the following APIs:

  • 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)
Sun.misc

The sun.misc package is internal and unsupported. In Red Hat build of OpenJDK 11, the following packages are deprecated or removed:

  • sun.misc.BASE64Encoder
  • sun.misc.BASE64Decoder
  • sun.reflect.Reflection

    In Red Hat build of OpenJDK 11, some methods were removed from the sun.misc.Unsafe package.

    Note

    Wherever possible, use public APIs instead of the sun.misc package components. For example, use the VarHandles package instead of the sun.misc.Unsafe package, or use the StackWalker API instead of the sun.reflect.Reflection API.

    An application’s use of classes in the sun.misc package is restricted in Red Hat build of OpenJDK 11. For more information about a workaround for this issue, see Java library classes.

Additional resources

  • For more information about Red Hat build of OpenJDK 8 features, see JDK 8 Features.
  • For more information about Red Hat build of OpenJDK 11 features, see JDK 11.
  • For more information about a list of all available JEPs, see JEP 0: JEP Index.
  • For more information about the removed Java EE modules and COBRA modules and potential replacements for these modules, see JEP 320: Remove the Java EE and CORBA Modules.