Migrating to Java Platform, Standard Edition 7 or 8

WebSphere® Application Server Version 8.5 supports the Java™ Platform, Standard Edition (Java SE) 6, 7, and 8 specifications, with Java SE 7.1 added in fix pack 8.5.5.2 and Java SE 8 added in fix pack 8.5.5.9. Support for using Java SE 6 with WebSphere Application Server ends in April 2018, but you can migrate to Java SE 8 to help ensure that your product installation remains secure.

About this task

Attention: [8.5.5.11 or later]Starting in version 8.5.5.11, the default versions of Java are Java SE 6 or Java SE 8. As such, you can accept the default and install either Java SE 6 or Java SE 8 as the version of Java SE contained in the /java and /java64 directories in WebSphere Application Server and used by default during server and node configuration. Java 8 is the recommended Java SDK because it provides the latest features and security updates. You can continue to use Java SE 6, but no service can be provided after the end of support in April 2018, which might expose your environment to security risks.
Java SE 7 and Java SE 7.1 (not available for Solaris and HP) are also viable options for installing on WebSphere Application Server version 8.5.5.11.
  • The bit level of Java SE 7.0 is based on the bit level selected during the initial installation of WebSphere Application Server. If a 32-bit WebSphere Application Server is installed, then only the 32-bit Java SE 7.0 can be installed. If a 64-bit WebSphere Application Server is installed, then only the 64-bit Java SE 7.0 can be installed.
  • Installing the optional Java SE 7.0 or Java SE 7.1 does not imply that profiles can take advantage of this new version of Java. The managesdk command can be used to switch Java or the WebSphere Application Server administrative console (wsadmin) can be used to make the switch.

[8.5.5.14 or later]Starting in version 8.5.5.14, Java SE 8 is the default Java. When updating to 8.5.5.14, any existing profile that uses Java SDK 6 is replaced by Java SDK 8. You can continue to use Java SDK Java Technology Edition Version 7.0 and Version 7.1, but no service can be provided after the end of support in July 2022, which could expose your environment to security risks.

For more information on Java SE 6, 7, and 7.1 end of service, see Java SE 6, 7, and 7.1 end of service in WebSphere Application Server V8.5.

The com.ibm.websphere.IBMJAVA.v80 offering will be deprecated, and no fix packs or interim fixes will be provided for this offering after March 2020. If this offering is installed with WebSphere Application Server Version 8.5.5 after March 2020, uninstall it and switch to the default Java SE 8 SDK provided by the WebSphere Application Server package in the same package group. With the default Java SE 8 SDK, you continue receiving Java SE 8 SDK support, including security updates.

[8.5.5.18 or later]Starting in version 8.5.5.18 for Linux on POWER8 Little Endian (LE), the default versions of Java are Java SE 7.1 or Java SE 8. As such, you can accept the default and install either Java SE 7.1 or Java SE 8 as the version of Java SE contained in the /java directory in WebSphere Application Server and used by default during server and node configuration. Java 8 is the recommended Java SDK because it provides the latest features and security updates. You can continue to use Java SE 7.1, but no service can be provided after the end of support in July 2022, which might expose your environment to security risks.

You can use the user.wasjava=java8 property only with new installations of the product for Linux on POWER8 LE. The user.wasjava=java8 property does not work for product upgrades through fix packs for Linux on POWER8 LE.

[8.5.5.19 or later]Starting in version 8.5.5.19 for Linux on POWER8 Little Endian (LE), the default version of Java is Java SE 8. As such, you can accept the default and install Java SE 8 as the version of Java SE contained in the /java directory in WebSphere Application Server and used by default during server and node configuration. You can continue to use Java SE 7.1 by installing IBM WebSphere Java SDK Version 7.1, but no service can be provided after the end of support in July 2022, which might expose your environment to security risks.

The user.wasjava=java8 property is not required for installing and updating to version 8.5.5.19 for Linux on POWER8 LE.

Migrating to Java SE 8 provides the latest available Java features and standards and ensures that your applications can run in a supported environment for years to come. For more information about new Java features, see What's new in Java 8 on the Oracle website.

Although you can also migrate to Java SE 7 or 7.1, support for these versions is provided only until July 2022. If you choose to migrate to Java SE 7 or 7.1, plan to perform a similar migration to Java SE 8 before that time. For more information about end of support for Java SE 6 and Java SE 7, see Removed features.

When you migrate to a newer Java SE version, decide whether to take advantage of any new Java SE capabilities in your applications, and begin the transition from deprecated functions.

Procedure

  1. Update your WebSphere Application Server installation to at least the minimum fix pack level that is required by the Java version.

    [8.5.5.11 or later]If you are starting with a new installation with Java SDK 8 as the default, you do not need to perform step 1.

    Table 1. Minimum fix pack levels by Java SE version. A two-column table that lists the Java SE version and the minimum product fix pack level that is required to install it.
    Java SE version Minimum fix pack level
    Java SE 8.0 8.5.5.9
    Java SE 7.1 8.5.5.2
    Java SE 7.0 8.5.0.0

    [AIX Solaris HP-UX Linux Windows]For detailed instructions, see Installing and uninstalling interim fixes and fix packs on distributed operating systems.

    [z/OS]For detailed instructions, see Installing and uninstalling interim fixes and fix packs on z/OS®.

  2. Install the newer Java SE version.
    [8.5.5.11 or later]Note: If you are starting with a new installation of version 8.5.5.11 or higher that uses Java SE 8 as the default, this step is not required.

    In Version 8.5, support for Java SE 7, 7.1, and 8 is provided only by IBM® WebSphere SDK, Java Technology Edition. These Java SDKs are packaged and tested specifically for WebSphere Application Server. Other Java SDKs, such as those provided for WebSphere Application Server Version 9.0 or Liberty, cannot be used.

    [AIX Solaris HP-UX Linux Windows]For detailed instructions, see Installing and uninstalling SDK Java Technology Edition Version 8.0 on distributed operating systems and Installing and uninstalling SDK Java Technology Edition Version 7.0 or 7.1 on distributed operating systems.

    [z/OS]For detailed instructions, see Installing IBM WebSphere SDK Java Technology Edition Version 8.0 or Installing IBM WebSphere SDK Java Technology Edition Version 7.0 or 7.1.

  3. Update the Java SDK that your WebSphere Application Server profiles use by running the managesdk command.
    [8.5.5.11 or later]Note: If you are starting with a new installation of version 8.5.5.11 or higher that uses Java SE 8 as the default, this step is not required.

    For more information, see managesdk command.

    1. Make sure that the new Java SDK is available by running managesdk -listavailable, and note the SDK name (such as 1.8_64) for later commands.
    2. Set the command default to the new SDK.
      managesdk -setCommandDefault -sdkname 1.8_64
    3. Set the new profile default to the new SDK.
      managesdk -setNewProfileDefault -sdkname 1.8_64
    4. Enable existing profiles to use the new SDK.
      managesdk -enableProfileAll -sdkname 1.8_64 -enableServers
  4. Update your existing applications as needed.
    1. Decide whether to take advantage of newer Java SE capabilities in your applications.

      You can deploy applications that use Java SE 8 features only to Version 8.5.5.9 or later nodes, and you can deploy applications that use Java SE 7.1 features only to 8.5.5.2 or later nodes. Earlier product versions do not provide the necessary Java SE virtual machine.

    2. Compile applications that do not use newer Java SE capabilities to run on previous Java virtual machine levels by setting the compiler modes.

      When you compile applications that are built with a newer Java SE version but are intended for running on previous specifications, specify -source and -target modes for the newer Java SE compiler. Doing so ensures that the bytecode that is generated is compatible with the earlier Java virtual machine.

      For example, if the target Java virtual machine is at 1.6 level, when you compile applications with Java SE 8, specify -source 1.6, and -target 1.6 to generate bytecode compatible with 1.6. This does not handle the usage of packages, classes, or functions new to Java SE 8. It addresses only bytecode output. Developers must take care in what APIs they are using from the Java SE packages if they intend to run the application on multiple Java virtual machine specification levels.

    3. Address any incompatibilities in previously compiled Java SE applications.

      In most cases, Java SE specifications are upwards binary-compatible with previous Java SE versions, except for the incompatibilities and deprecations that are documented in the Oracle Compatibility Guide for JDK 8 and Java SE 7 and JDK 7 Compatibility.

      Best practice: Rather than manually looking through your applications for API and specification changes, scan your applications for any required changes by using the Migration Toolkit for Application Binaries and the WebSphere Application Server Migration Toolkit.

      The application binary scanner provides a detailed migration analysis report for your application, so you can better understand the type and scope of changes that the application might require. When you migrate your applications, the Eclipse-based migration toolkit provides quick fixes to automatically update your source when possible and provides detailed help for items that must be manually updated.

      For more information and to download the toolkit, see the WebSphere Application Server Migration Toolkit.