The Road to Jakarta EE Compatibility
Payara Platform 5.194 was released recently, and just like the previous release, it’s a certified Jakarta EE implementation. The request for certification, which is the last step required for certification, is now on the Jakarta EE platform project issue tracker.
Here's what it took for Payara Server to become compatible with Jakarta EE.
Get the Jakarta EE TCK
The Jakarta EE Technology Compatibility Kit (TCK), also referred to as Compatibility Test Suite (CTS), can be downloaded from the Jakarta EE Platform website, or it can be built from source code, given enough time and determination.
The test suite is based on Java Test Harness — the tool used for running Java Development Kit (JDK) tests — as well as a large number of deployment descriptors and Apache Ant files to drive the execution. There are actually 50 percent more XML files in TCK distribution than there are Java files. In addition to this primary distribution, a compatible server also needs to pass TCKs for Context and Dependency Injection and Bean Validation that are distributed separately.
There are strict rules about what you are permitted to change in the files that make up the TCK. — primarily only the configuration file ts.jte and the porting package. This code facilitates management of the server and deployment of test applications. We benefitted from our roots in Eclipse GlassFish because we could use its porting package with only minor changes. Eclipse Foundation shell scripts that drive Glassfish certification were also very helpful.
Run TCK Test Cases
In total, we ran 49,850 TCK test cases. Each test case usually involves deployment to the application server or setting up an application client container and CORBA connection to the server. This takes time. The full test suite requires a little more than 119 hours or five full days.
Here, we were again able to learn from the efforts of Eclipse Foundation members, including ourselves, with regard to running TCK test suites in Jenkins. Like they did, we split the almost 50,000 test cases by technology or by vehicle — a term describing the technology in which API use is tested. For example, every Java Database Connectivity (JDBC) test is invoked in the context of Enterprise JavaBean (EJB), JavaServer Page (JSP), servlet, and application client containers. We ended up with 77 parts that we ran in parallel on nine Linux virtual machines.
With this approach, we received our full test report in less than 14 hours. When all tests passed, Jenkins provided us with the test results summary. If tests didn't pass, we also received test logs and server logs for inspection. We then needed to fix the server.
Publish the Test Results Summary and Request Certification
The test results summary is published as part of our documentation and serves as proof of compatibility, which we requested from the Jakarta Platform project using a GitHub issue, as described at the beginning of this article.
Running the Jakarta EE TCK has become part of our quarterly release process and our monthly patch release process. It helps ensure we deliver new functionality with each release, and that we can guarantee the same behavior for existing applications.
Looking Ahead
We’re looking into further improving this test process by shortening the configuration phases for partial jobs or even running parts of the suite on JDK 11. Due to classloading changes since Java 8, not all of the suites are capable of running on JDK 11, and these results will help us shape future Jakarta EE releases so they can become compatible with newer Java versions.
To learn more and get involved with the future of Jakarta EE, click here.
About the Author
