Chapter 2. Major differences between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11
If you are migrating your Java applications from Red Hat build of OpenJDK 8, first ensure that you familiarize yourself with the changes that were introduced in Red Hat build of OpenJDK 11. These changes might require that you reconfigure your existing Red Hat build of OpenJDK installation before you migrate to Red Hat build of OpenJDK 21.
This chapter is relevant only if you currently use Red Hat build of OpenJDK 8. You can ignore this chapter if you already use Red Hat build of OpenJDK 11 or later.
One of the major differences between Red Hat build of OpenJDK 8 and later versions is the inclusion of a module system in Red Hat build of OpenJDK 11 or later. If you are migrating from Red Hat build of OpenJDK 8, consider moving your application’s libraries and modules from the Red Hat build of OpenJDK 8 class path to the module class in Red Hat build of OpenJDK 11 or later. This change can improve the class-loading capabilities of your application.
Red Hat build of OpenJDK 11 and later versions include new features and enhancements that can improve the performance of your application, such as enhanced memory usage, improved startup speed, and increased container integration.
Some features might differ between Red Hat build of OpenJDK and other upstream community or third-party versions of OpenJDK. For example:
- The Shenandoah garbage collector is available in all versions of Red Hat build of OpenJDK, but this feature might not be available by default in other builds of OpenJDK.
- JDK Flight Recorder (JFR) support in OpenJDK 8 has been available from version 8u262 onward and enabled by default from version 8u272 onward, but JFR might be disabled in certain builds. Because JFR functionality was backported from the open source version of JFR in OpenJDK 11, the JFR implementation in Red Hat build of OpenJDK 8 is largely similar to JFR in Red Hat build of OpenJDK 11 or later. This JFR implementation is different from JFR in Oracle JDK 8, so users who want to migrate from Oracle JDK to Red Hat build of OpenJDK 8 or later need to be aware of the command-line options for using JFR.
- 32-bit builds of OpenJDK are generally unsupported in OpenJDK 8 or later, and they might not be available in later versions. 32-bit builds are unsupported in all versions of Red Hat build 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 versions of Red Hat build of OpenJDK 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 versions of Red Hat build of OpenJDK, so you can easily change from Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11 or later.
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 identical, 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 | Red Hat build of OpenJDK 11 |
---|---|
TLS clients do not use TLSv1.3 for communication with the target server by default. You can change this behavior by setting the | TLS clients use TLSv.1.3 by default. |
This release does not support the use of the |
This release supports the use of the |
This release still supports the legacy KRB5-based cipher suites, which are disabled for security reasons. You can enable these cipher suites by changing the | This release does not support the legacy KRB5-based cipher suites. |
This release does not support the Datagram Transport Layer Security (DTLS) protocol. | This release supports the DTLS protocol. |
The |
The |
2.2. Garbage collector
For garbage collection, Red Hat build of OpenJDK 8 uses the Parallel collector by default, whereas Red Hat build of OpenJDK 11 uses the Garbage-First (G1) collector by default.
Before you choose a garbage collector, consider the following details:
-
If you want to improve throughput, use the Parallel collector. The Parallel collector maximizes throughput but ignores latency, which means that garbage collection pauses could become an issue if you want your application to have reasonable response times. However, if your application is performing batch processing and you are not concerned about pause times, the Parallel collector is the best choice. You can switch to the Parallel collector by setting the
‑XX:+UseParallelGC
JVM option. - If you want a balance between throughput and latency, use the G1 collector. The G1 collector can achieve great throughput while providing reasonable latencies with pause times of a few hundred milliseconds. If you notice throughput issues when migrating applications from Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11, you can switch to the Parallel collector as described above.
- If you want low-latency garbage collection, use the Shenandoah collector.
You can select the garbage collector type that you want to use by specifying the ‑XX:+<gc_type>
JVM option at startup. For example, the ‑XX:+UseParallelGC
option switches to the Parallel collector.
2.3. Garbage collector logging options
Red Hat build of OpenJDK 11 includes a new and more powerful logging framework that works more effectively than 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 garbage collector logs.
Modified options in Red Hat build of OpenJDK 11
The old logging framework options are deprecated in Red Hat build of OpenJDK 11. These old options are still available only as aliases for the new logging framework options. If you want to work more effectively with Red Hat build of OpenJDK 11 or later, use the new logging framework options.
The following table outlines the changes in garbage collector logging options between Red Hat build of OpenJDK versions 8 and 11:
Options in Red Hat build of OpenJDK 8 | Options in Red Hat build of OpenJDK 11 |
---|---|
|
|
|
|
|
or
|
|
|
When using the -XX:+PrintGCDetails
option, pass the -Xlog:gc*
flag, where the asterisk (*
) activates more detailed logging. Alternatively, you can pass the -Xlog:gc+$tags
flag.
When using the -Xloggc
option, append the :file=$FILE
suffix to redirect log output to the specified file. For example -Xlog:gc:file=$FILE
.
Removed options in Red Hat build of OpenJDK 11
Red Hat build of OpenJDK 11 does not include the following options, which were deprecated in Red Hat build of OpenJDK 8:
-
-Xincgc
-
-XX:+CMSIncrementalMode
-
-XX:+UseCMSCompactAtFullCollection
-
-XX:+CMSFullGCsBeforeCompaction
-
-XX:+UseCMSCollectionPassing
Red Hat build of OpenJDK 11 also removes the following options because the printing of timestamps and datestamps is automatically enabled:
-
-XX:+PrintGCTimeStamps
-
-XX:+PrintGCDateStamps
In Red Hat build of OpenJDK 11, unless you specify the -XX:+IgnoreUnrecognizedVMOptions
option, the use of any of the preceding removed options results in a startup failure.
Additional resources
-
For more information about the common framework for unified JVM logging and the format of
Xlog
options, see JEP 158: Unified JVM Logging. - For more information about deprecated and removed options, see JEP 214: Remove GC Combinations Deprecated in JDK 8.
- For more information about unified GC logging, see JEP 271: Unified GC Logging.
2.4. OpenJDK graphics
Before version 8u252, Red Hat build of OpenJDK 8 used Pisces as the default rendering engine. From version 8u252 onward, Red Hat build of OpenJDK 8 uses Marlin as the new default rendering engine. Red Hat build of OpenJDK 11 and later releases also use Marlin by default. Marlin improves the handling of intensive application graphics.
Because the rendering engines produce the same results, users should not observe any changes apart from improved performance.
2.5. Webstart and applets
You can use Java WebStart by using the IcedTea-Web plug-in with Red Hat build of OpenJDK 8 or Red Hat build of OpenJDK 11 on RHEL 7, RHEL 8, and Microsoft Windows operating systems. The IcedTea-Web plug-in requires that Red Hat build of OpenJDK 8 is installed as a dependency on the system.
Applets are not supported on any version of Red Hat build of OpenJDK. Even though some applets can be run on RHEL 7 by using the IcedTea-web plug-in with OpenJDK 8 on a Netscape Plugin Application Programming Interface (NPAPI) browser, Red Hat build of OpenJDK does not support this behavior.
The upstream community version of OpenJDK does not support applets or Java Webstart. Support for these technologies is deprecated and they are not recommended for use.
2.6. JPMS
The Java Platform Module System (JPMS), which was introduced in OpenJDK 9, limits or prevents access to non-public APIs. JPMS also impacts how you can start and compile your Java application (for example, whether you use a class path or a module path).
Internal modules
By default, Red Hat build of OpenJDK 11 restricts but still permits access to JDK internal modules. This means that most applications can continue to work without requiring changes, but these applications will emit a warning. As a workaround for this restriction, you can enable your application to access an internal package by passing a ‑‑add-opens <module-name>/<package-in-module>=ALL-UNNAMED
option to the java
command.
For example:
--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 Red Hat build of OpenJDK.
ClassLoader
The JPMS refactoring changes the ClassLoader
hierarchy in Red Hat build of OpenJDK 11.
In Red Hat build of OpenJDK 11, the system class loader is no longer an instance of URLClassLoader
. Existing application code that invokes ClassLoader::getSystemClassLoader
and casts the result to a URLClassLoader
in Red Hat build of OpenJDK 11 will result in a runtime exception.
In Red Hat build of OpenJDK 8, when you create a class loader, you can pass null
as the parent of this class loader instance. However, in Red Hat build of OpenJDK 11, applications that pass null
as the parent of a class loader might prevent the class loader from locating platform classes.
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. In Red Hat build of OpenJDK 11, when you create a class loader instance, you can set the platform class loader as its parent by using the ClassLoader.getPlatformClassLoader()
API.
Additional resources
- For more information about JPMS, see JEP 261: Module System.
2.7. Extension and endorsed override mechanisms
In Red Hat build of OpenJDK 11, both the extension mechanism, which supported optional packages, and the endorsed standards override mechanism are no longer available.
These changes mean that any libraries that are added to the <JAVA_HOME>/lib/ext
or <JAVA_HOME>/lib/endorsed
directory are no longer used, and Red Hat build of OpenJDK 11 generates an error if these directories exist.
Additional resources
- For more information about the removed mechanisms, see JEP 220: Modular Run-Time Images.
2.8. JFR functionality
JDK Flight Recorder (JFR) support was backported to Red Hat build of OpenJDK 8 starting from version 8u262. JFR support was subsequently enabled by default from Red Hat build of OpenJDK 8u272 onward.
The term backporting describes when Red Hat takes an update from a more recent version of upstream software and applies that update to an older version of the software that Red Hat distributes.
Backported JFR features
The JFR backport to Red Hat build of OpenJDK 8 included all of the following features:
- A large number of events that are also available in Red Hat build of OpenJDK 11
-
Command-line tools such as
jfr
and the Java diagnostic command (jcmd
) that behave consistently across Red Hat build of OpenJDK versions 8 and 11 -
The Java Management Extensions (JMX) API that you can use to enable JFR by using the JMX beans interfaces either programmatically or through
jcmd
The
jdk.jfr
namespaceNoteThe JFR APIs in the
jdk.jfr
namespace are not considered part of the Java specification in Red Hat build of OpenJDK 8, but these APIs are part of the Java specification in Red Hat build of OpenJDK 11. Because the JFR API is available in all supported Red Hat build of OpenJDK versions, applications that use JFR do not require any special configuration to use the JFR APIs in Red Hat build of OpenJDK 8 and later versions.
JDK Mission Control, which is distributed separately, was also updated to be compatible with Red Hat build of OpenJDK 8.
Applications that need to be compatible with other OpenJDK versions
If your applications need to be compatible with any of the following OpenJDK versions, you might need to adapt these applications:
- OpenJDK versions earlier than 8u262
- OpenJDK versions from other vendors that do not support JFR
- Oracle JDK
To aid this effort, Red Hat has developed a special compatibility layer that provides an empty implementation of JFR, which behaves as if JFR was disabled at runtime. For more information about the JFR compatibility API, see openjdk8-jfr-compat. You can install the resulting .jar
file in the jre/lib/ext
directory of an OpenJDK 8 distribution.
Some applications might need to be updated if these applications were filtering out OpenJDK 8 by checking only for the version number instead of querying the MBeans interface.
2.9. JRE and headless packages
All Red Hat build of OpenJDK versions for RHEL platforms are separated into the following types of packages. The following list of package types is sorted in order of minimality, starting with the most minimal.
- Java Runtime Environment (JRE) headless
- Provides the library only without support for graphical user interface but supports offline rendering of images
- JRE
- Adds the necessary libraries to run for full graphical clients
- JDK
- Includes tooling and compilers
Red Hat build of OpenJDK versions for Windows platforms do not support headless packages. However, the Red Hat build of OpenJDK packages for Windows platforms are also divided into JRE and JDK components, similar to the packages for RHEL platforms.
The upstream community version of OpenJDK 11 or later does not separate packages in this way and instead provides one monolithic JDK installation.
OpenJDK 9 introduced a modularised version of the JDK class libraries divided by their namespaces. From Red Hat build of OpenJDK 11 onward, these libraries are packaged into jmods
modules. For more information, see Jmods.
2.10. Jmods
OpenJDK 9 introduced jmods
, which is a modularized version of the JDK class libraries, where each module groups classes from a set of related packages. You can use the jlink
tool to create derivative runtimes that include only some subset of the modules that are needed to run selected applications.
From Red Hat build of OpenJDK 11 onward, Red Hat build of OpenJDK versions for RHEL platforms place the jmods
files into a separate RPM package that is not installed by default. If you want to create standalone OpenJDK images for your applications by using jlink
, you must manually install the jmods
package (for example, java-11-openjdk-jmods
).
On RHEL platforms, OpenJDK is dynamically linked against system libraries, which means the resulting jlink
images are not portable across different versions of RHEL or other systems. If you want to ensure portability, you must use the portable builds of Red Hat build of OpenJDK that are released through the Red Hat Customer Portal. For more information, see Installing Red Hat build of OpenJDK on RHEL by using an archive.
2.11. Deprecated and removed functionality in Red Hat build of OpenJDK 11
Red Hat build of OpenJDK 11 has either deprecated or removed some features that Red Hat build of OpenJDK 8 supports.
- CORBA
Red Hat build of OpenJDK 11 does not support the following Common Object Request Broker Architecture (CORBA) 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
-
- java.awt.peer
Red Hat build of OpenJDK 11 sets the
java.awt.peer
package as internal, which means that applications cannot automatically access this package by default. Because of this change, Red Hat build of OpenJDK 11 removed a number of classes and methods that refer to the peer API, such as theComponent.getPeer
method.The following list outlines the most common use cases for the peer API:
- Writing of new graphics ports
- Checking if a component can be displayed
- Checking if a component is either lightweight or backed by an operating system native UI component resource such as an Xlib XWindow
From Java 1.1 onward, the
Component.isDisplayable()
method provides the functionality to check whether a component can be displayed. From Java 1.2 onward, theComponent.isLightweight()
method provides the functionality to check whether a component is lightweight.- 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
has always been considered internal and unsupported. In Red Hat build of OpenJDK 11, the following packages are deprecated or removed:-
sun.misc.BASE64Encoder
-
sun.misc.BASE64Decoder
-
sun.misc.Unsafe
-
sun.reflect.Reflection
Consider the following information:
-
Red Hat build of OpenJDK 8 added the
java.util.Base64
package as a replacement for thesun.misc.BASE64Encoder
andsun.misc.BASE64Decoder
APIs. You can use thejava.util.Base64
package rather than these APIs, which have been removed from Red Hat build of OpenJDK 11. -
Red Hat build of OpenJDK 11 deprecates the
sun.misc.Unsafe
package, which is scheduled for removal. For more information about a new set of APIs that you can use as a replacement forsun.misc.Unsafe
, see JEP 193. -
Red Hat build of OpenJDK 11 removes the
sun.reflect.Reflection
package. For more information about new functionality for stack walking that replaces thesun.reflect.Reflection.getCallerClass
method, see JEP 259.
-
Additional resources
- For more information about the removed Java EE modules and CORBA modules and potential replacements for these modules, see JEP 320: Remove the Java EE and CORBA Modules.
2.12. Additional resources (or Next steps)
- For more information about Red Hat build of OpenJDK 8 features, see JDK 8 Features.
- For more information about OpenJDK 9 features inherited by Red Hat build of OpenJDK 11, see JDK 9.
- For more information about OpenJDK 10 features inherited by Red Hat build of OpenJDK 11, see JDK 10.
- 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 changes introduced in version 17, see Major differences between Red Hat build of OpenJDK 11 and Red Hat build of OpenJDK 17.
- For more information about the changes introduced in version 21, see Major differences between Red Hat build of OpenJDK 17 and Red Hat build of OpenJDK 21.