Gen 8.6 supported Liberty Application Server and Java versions
Article ID: 431773
Updated On:
Products
Issue/Introduction
Currently have quite a lot of Gen Server Procedures generated and implemented as EJB Web Services deployed on IBM WebSphere Liberty on z/OS v2.3 with the Java as inbuilt IBM Java version 8.0.6.25 in Production.
Planning to upgrade the Liberty and also the underlying Java on Liberty. So would like to know the Java versions supported by Gen for EJB Web Services (SOAP Services) Generation, Builds and Runtimes.
User Exits are also customised and compiled with Java 8.
Also have a few common Libraries downloaded from the internet like jt400.jar etc., and few other new jar files that have been created with some new custom classes/functions (compiled using java 8) that are used in inline code.
Also for the Java EE libraries, currently using Glassfish 5 J2EE SDK 8.1 (LOC.JAVAEE_HOME in Build Tool profile).
To build for Liberty currently the assemble option "Application Server = GENERIC" is used because have been using it since before Gen officially supported Liberty which was only recently. (Other changes were made to ensure the Gen applications/runtimes would run under Liberty successfully).
Also what are the necessary steps that need to be followed for any necessary upgrade in Java on the Developer machines where Toolset is installed?
Environment
Gen 8.6 with Liberty Application Server
Resolution
1. For supported Java versions the Gen 8.6 techdocs is the best source for this information as it changes over time.
In particular please see this page: Gen™ 8.6 > Technical Requirements > Third-Party Software Version
See Compilers section for supported Java JDK versions for building and the Application Servers section for supported Java JRE versions at runtime.
The supported JDK versions for the Build Tool are now 8, 11, 17, 21 & 25
The support for 17, 21 & 25 was released with BTN86407/LU19622 (superseded BTN86406)
Also see this page for all the latest Gen 8.6 PTFs: Gen 8.6 Solutions & Patches
2. For the other points:
a. Liberty Application Server support phases 1 & 2 are now complete to give full support.
Here is the Gen EDGE Community support announcement after the completion of phase #2 with the corresponding *864* Liberty PTF links (they are also listed on the Gen 8.6 Solutions & Patches page): Now Available: Full Support for Websphere Liberty and Open Liberty as Application Servers
b. Going forward if wish to move to using the "Application Server = Liberty" option then the Liberty PTFs would need to be installed.
c. Java version options with "Application Server = Liberty" :
- To continue to use JDK 1.8 just requires to reassemble the applications using the "Application Server = Liberty" option.
- To upgrade to JDK 11 does not require any new Build Tool PTF as JDK 11 support is already in the "Gen 8.6.4 Consolidation" PTF WKS86400. The applications would need to be recompiled with that JDK and reassembled using the "Application Server = Liberty" option.
- To upgrade to JDK 17, 21 or 25 requires installing the new Build Tool PTF BTN86407. The applications would need to be recompiled with the new JDK and reassembled using the "Application Server = Liberty" option.
d. For the actual WebSphere Liberty support, page Gen™ 8.6 > Technical Requirements > Third-Party Software Version section "Application Servers" covers that.
Version 24.0.0.x is listed with note 6. Also notes 4 & 5 are shown:
*****
4 The Java EE 8 full profile feature (javaee-8.0) was used for our Liberty certification. Depending upon the requirements of your applications, you may be able to use a subset of the features included in the Java EE 8 full profile feature.
5 WebSphere Liberty on z/OS is not supported now.
6 And subsequent Continuous Delivery offerings. See Liberty support lifecycle policy on the IBM website.
Currently you are using WebSphere Liberty on z/OS v23 without any problems, but per above Gen does not officially support Liberty under z/OS. That does not mean it will not function correctly but it has not been tested or certified. If encounter problems the Gen Support Policy applies per this page: Gen™ 8.6 > Technical Requirements > General Comments
3. Other useful knowledge articles
Gen 8.6 Java applications under Liberty Application Server hub article
Gen 8.6 Build Tool profile JAVA tokens for JDK compiler versions 11, 17, 21, 25
Additional Questions
Q4. How to make sure, that the Build Tool is using the new required Java version (21 or 25 etc.,),
Will the contents in the Build Output Review file be enough to arrive at this conclusion?
A4. Yes the Build Tool (BT) review file <server_manager>.out will now confirm the JDK version used by the Build Tool.
PTF BTN86407 adds JDK version output from command "java -version" which was not there previously e.g.
*****openjdk version "1.8.0_362"OpenJDK Runtime Environment (Temurin)(build 1.8.0_362-b09)OpenJDK 64-Bit Server VM (Temurin)(build 25.362-b09, mixed mode)
*****
Previous to that PTF the value of LOC.JDK_HOME in the file <server_manager>.tgt would have been the best way to check.
Q5. Since the Production Liberty Version is 23 with Java 8, it is understood that later JDK 11 or above version cannot be used on Developer Workstation for compile with Build Tool and Assemble the Applications to be deployed in Liberty.
Only once the Java Version in the Application Server is upgraded, will the corresponding JDK version be able to be used on Workstations (same or the lower Java version than the version supported by Application Server) to compile in the Build Tool. Is that correct?
A5. Correct, due to Java runtime class version compatibility being backwards only, the JDK version used by the Build Tool to build applications must be less than or equal to the JRE version used by Liberty.
Q6. It also understood that after upgrading Liberty and its corresponding JRE (to Java 11 or higher), the existing EJB Web Service Applications (built with Java 8) with run without any issue since Java is backward compatible, is this correct?
This will enable building with JDK 11 or higher and deploying only when there are any code changes to that application instead of doing it by default for all the applications.
A6. Correct, due to the same Java runtime class version backward compatibility as in "b)" above, the JDK version used to build applications can be less than the JRE version used in Liberty.
That assumes those existing Java 8 applications have been previously regenerated and built after installing the Liberty Application Server (Phase 2) PTFs which are BTN86403 and GEN86407 (assuming all generation is from Workstation Toolset and not a CSE which requires separate PTFs per page Gen 8.6 Solutions & Patches).
In theory if using only EJB Web Services and not EJBRMI the Liberty phase 1 PTFs might be enough for (Now Available: Support for Liberty (Phase 1)). They were all pre-WKS86400 so WKS86400 supersedes them. However generations and runtimes would still be needed at level WKS86400.
Then the new BTN86407 PTF is required on top of that plus its pre-reqs.
So it is cleaner to have all the latest PTFs installed including the Liberty phase 2 PTFs.
Q7. Also the current Gen Runtimes, and other necessary custom Classes (created and used in a common file set in Liberty so that they don't need to be included in each and every application ) are currently compiled with Java 8. So even if upgrade the JRE in Liberty to 11 or higher, they can continue to be used due to backward compatibility?
A7. Correct, due to the same Java runtime class version backward compatibility as per above.
NOTE: Also in the context of above if only rebuilding some applications with JDK 11, another thing to be aware of is that if using common Gen runtimes across all applications they will have to remain at Java 8 until ALL the applications have been built with JDK 11. That is because JDK 8 built applications will not be able to use JDK 11 built runtimes.
Additional Information
Feedback
