Diagnosing runtime problems

Some applications might experience problems when running on this version of the SDK due to changes imposed by the Java module system and changes to underlying components of the runtime environment.

We recommend that you read about Version compatibility before you attempt to run your application in a Java 11 runtime environment. This information helps you understand dependencies that your existing applications have on aspects of the runtime environment that are changed in this release. However, if you choose to test your applications without establishing dependencies, or some dependencies are missed, this topic covers some of the errors that you might encounter. By identifying the cause of an error, you can determine what action to take to correct the problem.

Some of the changes that are imposed by the Java module system might cause compatibility issues with existing Java applications. The following list summarizes these changes, indicating the type of operation that might fail:
Internal APIs are no longer available.
  • Although internal APIs are private and not intended for use, many were accessible to applications. By default in Java 11, access to internal APIs is allowed at run time for packages that were present in Java 8, although a warning is printed the first time an access occurs. However, most internal APIs are not accessible at compile time.
  • As a temporary workaround you can use the –add-exports option on the command line to break encapsulation. For accessing an internal API by using reflection, use the -add-opens option.
Limitations of --release option with javac
  • When you compile Java code that uses Semeru specific packages like JZOS and IBM specific security providers, avoid usage of the --release option with the javac command. The --release option restricts the usage to Java SE and JDK APIs, resulting in Semeru packages and extensions becoming unavailable at compile time.
The structure of the runtime image is changed.
  • Modularity removes the concept of a developer kit and a Java Runtime Environment as distinct entities. A modular runtime image is simply built to contain the components that are needed, which might include a subset of tools. One consequence of this design is the removal of the /jre directory. Issues are likely to arise if existing applications depend on the current structure of runtime images.
  • Configuration files, such as java.security and logging.properties, are now located in a new directory, /conf, and its subdirectories.
The endorsed-standards override mechanism is removed.
  • This mechanism, which involves placing JAR files on the jre/lib/endorsed path, is used in Java 8 to implement newer versions of standards that are maintained outside of the Java Community Process. Endorsed standards will be supported only in a modular form with the new concept of upgradeable modules. The java.endorsed.dirs system property is no longer defined. Code that assumes a non-null value for this system property might fail.
The extensions mechanism is removed.
  • The extensions mechanism can be used to install additional APIs into a runtime image, by placing jar files into an extensions directory, lib/ext. The ext directory no longer exists in a modular image and applications that rely on this mechanism will fail. The java.ext.dir system property is no longer defined. Code that assumes a non-null value for this system property might fail.
The rt.jar, tools.jar, and dt.jar files are removed.
  • JAR files are replaced by modules in the new system. Code that depends on finding these JAR files will fail. As an alternative, consider using the jrt: file system, intended for modular class files, as described in JEP 220, New URI scheme for naming stored modules, classes, and resources, item (3). More information is also available in the Oracle migration documentation.
The bootstrap class path option is removed.
  • The default bootstrap class path can no longer be overridden, nor can you prepend the path with files and directories. If you attempt to use this option at runtime, the option is ignored. Note that -Xbootclasspath/a continues to be supported for appending to the end of the bootstrap class path.
New class loader implementations
The following changes apply, as described in more detail in Class loader implementations:
  • The application class loader is now an instance of an internal class.
  • The extension class loader is now renamed to the platform class loader. It is also an instance of an internal class.
This version of the IBM SDK and runtime environment includes changes to functional components. The following list summarizes these changes, indicating the type of operation that might fail:
Security implementation
In this release, the OpenJDK security implementation replaces many of the components in the IBM® security implementation. Your application will fail if it attempts to use one of the following providers:
  • IBM JSSE2 provider
  • IBM JCE provider
  • IBM JCEFIPS provider
  • IBM JGSS provider
  • IBM Certification Path provider
  • BM SASL provider
  • IBM JAAS provider
  • IBM SecureRandom provider
  • XML Digital Encryption
If your application makes calls to these providers, you must update your application code to use the equivalent OpenJDK security providers instead, where available (for the IBM JCE provider, you can in most cases use the IBM OpenJCEPlus provider instead). To understand which OpenJDK providers are included in the SDK, see Determining application compatibility: security. Any differences between the IBM and equivalent OpenJDK providers are detailed in that section.

In addition, the following security providers and components are not present in the initial release of IBM Semeru Runtime Certified Edition for z/OS®, 11:
  • IBMJCECCA provider
  • IBMJCEHYBRID provider
  • JCERACFKS Keystore implementation
  • JAAS z/OS extensions
  • IBM PKCS11Impl provider
  • ZERTJSSE provider
  • iKeyman utility
  • IBM Key Certificate Management utility
For information about the future of these components, see the IBM Semeru Runtime Certified Edition for z/OS, Version 11: Supplementary documentation technote.
XML implementation
The IBM implementation of XML is replaced with the OpenJDK implementation of XML. Your application is likely to fail if it has a dependency on IBM XML APIs. Use the binaryAppScanner tool to identify dependencies in your application. For more information about this tool and recommended alternatives to the IBM XML APIs, see Determining application compatibility: XML.