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

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 Red Hat build 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 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:

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

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:

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>.

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.

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.

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.

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

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 8 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.

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.

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

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