If you’re using Java SE 6 on WebSphere traditional or Liberty, it’s time to update!

By Cindy High and Carolyn Carpenter

Perhaps you’ve seen some of the recent Java SE 6 end of support messages from IBM and wondered about the effect on WebSphere Application Server. In short, public updates for Java SE 6 are no longer available, and the end of support in WebSphere is set for April 2018 (September 2017 for Liberty). But what does that mean for your current WebSphere installations?

End of support for Java SE 6 means you can’t get updates or fixes for Java problems such as security vulnerabilities. Staying on the Java SE 6 level could leave your applications exposed to future issues. To ensure your applications are running in a supported environment for years to come, we recommend moving to the latest Java — Java SE 8. Although Java SE 7 also is an option, its support only runs through September 2019 for Liberty and until July 2022 for traditional WebSphere .

To move off Java SE 6, you’ll need an application server that supports Java SE 7 or 8 – and you’ve got choices! Newer versions of Java SE are supported on Liberty and traditional WebSphere V8.5 and V9.

Application server Java SE 6 Java SE 7.0 Java SE 7.1 Java SE 8
WebSphere Application Server Liberty Ends
Sept 2017
Sept 2019
Sept 2019

WebSphere Application Server traditional V9.0
WebSphere Application Server traditional V8.5 Ends
April 2018
July 2022
July 2022

WebSphere Application Server V8.0
(EOS announced)
April 2018
WebSphere Application Server V7.0
(EOS announced)
April 2018

If you’re currently running traditional WebSphere V8.5 with Java 7 or 8, traditional WebSphere V9, or Liberty with Java 7 or 8, good news – you’re already in great shape! There’s no need for you to update at this time.

Are you using WebSphere V8 or earlier?

If you’re using WebSphere V8, V7, or earlier (and we know you are out there), it’s time to migrate to a newer version. Although the easiest path is to move to WebSphere V8.5 or V9, you can use this opportunity to consider what your next-gen platform looks like. Will you move some workloads to Liberty and gain the benefits that so many customers have come to love, like flexible config and a lightweight, composable runtime? Will you consider Docker containers, IBM Cloud instant runtimes, or WebSphere on Cloud services and let us deal with the environment upgrade? Or will you upgrade traditional WebSphere Application Server on-premises using the processes you have perfected?

To help you work though these questions, we have lots of information and guidance in these online resources:

  • The Migration Strategy Tool helps you understand the migration alternatives for the future of your WebSphere applications.
  • The WebSphere Application Server Migration Discovery Tool helps you compare cloud environments and size the effort required to migrate to your chosen environment.
  • The WebSphere Migration Knowledge Collection is your one-stop resource for migration planning information and links.
  • The WebSphere Application Server Migration Toolkit source and binary scanners are essential tools for understanding differences between WebSphere versions, Java SE versions, and much more. The tools analyze your applications for potential migration issues and identify and help fix any deprecations, removals, and behavior changes. When you use the tools:
    1. First, evaluate, inventory, and analyze your applications by using the command-line application binary scanner, which provides several reports to help assess what’s required to migrate your applications:
      • The application evaluation report evaluates the technologies in your application to find the best-fit application platform.
      • The inventory report identifies the contents of your applications, such as entity beans, session beans, and Servlets.
      • The detailed migration analysis report helps you better understand the type and scope of changes that your applications might require. The report also includes detailed help to assist with the analysis of the potential migration issues.
    2. Then, if necessary, migrate your application source code with help from the Eclipse-based source scanner, which:
      • Identifies deprecations, removals, and behavior changes that affect the application
      • Provides quick fixes to automatically make updates when possible
      • Provides detailed help for solving each migration issue

Are you using WebSphere V8.5 with Java 6?

If you are using WebSphere traditional V8.5 or Liberty with Java SE 6, your current installations require updates to make sure you stay supported for years to come. We also recommend you scan your applications to be aware of those small corner-case differences that can exist between versions of Java. Here’s what you need to do:

  1. Update to a fix pack that supports your target Java version.
  2. Update the JRE or Java SDK in the WebSphere runtime environment.
  3. Scan your applications with the Migration Toolkit to understand any differences in the later Java level. This step can be done concurrently with your installation updates.

1. Update the WebSphere fix pack

Update your installation to at least the minimum fix pack level (although later is better).

WebSphere Application Server traditional V8.5
For Java SE 8 support on WebSphere traditional V8.5, you’ll need fix pack or later. Java SE 7.1 requires fix pack or later. Java SE 7.0 is supported on V8.5.0.0. You can install the fix packs from the online repositories (recommended) or download the fix pack parts from IBM Fix Central. For detailed installation instructions, see Installing and uninstalling interim fixes and fix packs.


You can get an updated Liberty and Java all in one package in the WAS Liberty with Java EE 7 Web Profile and IBM Java SDK 8 ZIP file [WASdev.net | IBM Fix Central]! The packaged IBM Java SDK is updated to the latest level with each Liberty fix pack and can also be independently updated.

If you manage Liberty and Java updates separately, Java SE 8 support requires fix pack V8.5.5.5 or later, and Java SE 7.1 requires V8.5.5.2 or later. For archive installation, you can download the latest fix pack ZIP or JAR file from WASdev.net. If you’re using Installation Manager (which you’ll need if you want to install IBM Java 8), you can update from the online repositories (recommended) or download the fix pack parts from Fix Central.


2. Update the Java SDK or JRE

WebSphere Application Server traditional V8.5 and Liberty support multiple Java SE versions, which you can update as follows:

WebSphere Application Server traditional V8.5
WebSphere traditional V8.5 supports only the WebSphere Java SDKs, which are different from the WebSphere Java SDKs for Liberty and the new common IBM Java SDK for Version 9.0.

  1. Installing and uninstalling SDK Java Technology Edition Version 8.0. Just like before, you can install Java from the online repositories or from downloaded files from IBM Fix Central. For example, to install Java 8 from the online repository using the GUI:
    1. In the Installation Manager GUI, go to File > Preferences and add the following repository:
    2. Click Install, select IBM WebSphere SDK Java Technology Edition (Optional), and follow the GUI to install the SDK in your V8.5 installation.
  1. Run the managesdk command to change the SDK used by each profile.
    1. Make sure the new Java SDK is available by running managesdk.bat|sh -listAvailable, and note the SDK name (such as 1.8_64) for later commands.
    2. Set the command default to the new SDK by running managesdk -setCommandDefault -sdkname 1.8_64.
    3. Set the new profile default to the new SDK by running managesdk -setNewProfileDefault -sdkname 1.8_64.
    4. Enable existing profiles to use the new SDK by running managesdk -enableProfileAll -sdkname 1.8_64 -enableServers.

Liberty can run on any standards-compliant Java runtime environment (JRE) or Java SDK – unlike WebSphere traditional, you don’t have to use Java provided by IBM.

If you do use IBM Java, install one of the common IBM Java SDKs, such as IBM SDK, Java Technology Edition, Version 8. You’ll get security updates faster than the older WebSphere Java SDKs because they aren’t on the WebSphere fix pack schedule. The IBM Java 8 SDK is also used by WebSphere traditional V9.0.

Your options for updating the Liberty JRE or Java SDK include:

  • Install Liberty and IBM Java 8 from the Java EE 7 Web Profile ZIP file as already described.
  • Install one of the common IBM Java SDKs using Installation Manager. Note that to install the IBM Java SDKs using Installation Manager, you must have also installed Liberty (or WebSphere traditional V9.0) by using Installation Manager.
  • Install a separately downloaded Java SDK and point to the new Java SDK using the JAVA_HOME variable.
    1. Install the new JRE or Java SDK. For example, you can download and install IBM SDK, Java Technology Edition, Version 8.
    1. Change the Java level that Liberty uses by setting the JAVA_HOME variable. For example, from the Windows 7 control panel, go to System > Advanced system settings. In the Advanced tab of the System Properties window, click Environment Variables. Add or edit the JAVA_HOME system variable so that it points to the jre directory of the Java installation, such as C:Program FilesIBMJava80jre.


3. Scan your applications with the Migration Toolkit

New versions of Java strive to maintain compatibility with previous versions, but sometimes there are differences as described in Java SE 7 and JDK 7 Compatibility and Compatibility Guide for JDK 8. You can use the WebSphere migration toolkit, either the Eclipse source scanner and the command-line binary scanner, to scan your applications for Java SE compatibility differences. Most of the Java API differences are corner-case changes that don’t require application changes, but they are good to be aware of during testing.

For developers using Eclipse, the source scanner brings the power of the migration toolkit to the development environment. The binary scanner allows you to quickly scan application with only the application binaries if perhaps you don’t use Eclipse or you don’t have the source readily available. When using either tool, you choose the version of Java you are currently using and the version you are migrating to scan your application for the differences.

When you’re just migrating Java versions, you can use either the source scanner or the command line application binary scanner to see the Java SE behavior differences. From the command line, it is as simple as running a single command:

C:wamt>java -jar binaryAppScanner.jar .myApp.ear --analyze --sourceJava=ibm6 --targetJava=ibm8 --sourceAppServer=was855 --targetAppServerr=was855

How to keep ahead of future changes

Now that WebSphere can support multiple versions of Java SE, we will generally follow this pattern:

  • Support for new Java SE versions will be added for Liberty soon after these Java versions become available.
  • Support for new Java SE versions will be considered for WebSphere traditional after the Liberty support completes.
  • Support for old Java SE versions will usually be withdrawn according to the IBM Java support lifecycle.

For answers to all of your WebSphere migration questions, visit the migration knowledge collection.

16 comments on"The end of Java SE 6: Where to go from here"

  1. Hello, this URL http://www.ibm.com/software/repositorymanager/com.ibm.websphere.IBMJAVA.v80
    Error 404: java.io.FileNotFoundException: SRVE0190E: File not found: /com.ibm.websphere.IBMJAVA.v80

    • I get that message too when I open it in a browser but it should work in Installation Manager – can you try that, please, then let me know if it’s still not working?

  2. Hariprasad Chandrasekaran January 25, 2018

    We are trying to stick with Java 6 while upgrading to WAS 9. IS there any way that it could have downward compatibility to support EAR compiled in Java 6

  3. […] end of of commercial JDK 6 support is coming up soon, with Oracle declaring December 2018 and IBM declaring April 2018 as the end of their extended […]

  4. We have WAS 8.5.5 installed which when we applied fix pack 12 to bring it to Now we want to upgrade / install Java 7.0 but the Installation Manager 1.8.0 is not recognizing the WAS-Java-7.0 repository. What could be the issue?

    • Hi Arun,

      Check if you have the base level of the Java SDK 7 package available in one of your repositories. If not, locate that and make it available to Installation Manager.

      Installation Manager should recognize and allow you to install and/or update if all the pieces are available.

      Hope this helps.

  5. Mihir_Shah April 05, 2017

    Is it possible to uninstall WebSphere Java SDK 6 (which gets installed by default with v8.5)) after updating to WebSphere Java SDK 8 ?

  6. Hi, with 855.11 can I default to Java 7.1? (IBM WebSphere SDK Java Technology Edition Version 7.1)
    To install Java SE 8, specify -properties user.wasjava=java8.
    To install Java SE 6, specify -properties user.wasjava=java6

    can I also use
    user.wasjava=java71 ?

  7. This link doesn’t seem to work:
    “recent Java SE 6 end of support messages from IBM”

Join The Discussion

Your email address will not be published. Required fields are marked *