Restructuring the Jakarta EE TCK

The Jakarta EE Technology Compatibility Kit (TCK) is a crucial part of any Jakarta EE release. Every implementation designed to work with Jakarta EE needs to demonstrate full compatibility with the platform, not to mention any relevant component specifications, and as such it’s crucial that the TCK be accurate and up-to-date.

But the existing TCK presents some challenges for developers. For one thing, it has a steep learning curve, which makes it difficult for new contributors to get involved. This is a serious concern for such a fundamental aspect of the Jakarta ecosystem. And the existing test kit relies on old technologies, most notably Apache ANT and the Java Test Harness, which are not widely used anymore.

For the past few years there’s been ongoing work to update, modernize, and streamline the test kit. And with Jakarta EE 11 on the horizon, there’s no better time to have a modernized and easy-to-use TCK ready to go.

Accessible TCK Crucial to Jakarta EE

There are two main reasons why it’s so important that the TCK be easy-to-use and accessible.

The first is that the TCK is the crucial enabler that makes Jakarta EE useful to the broader community. If there’s no way to test the compatibility of specifications, there’s no reliability. Having an up-to-date and effective TCK ensures there’s a strong basis for specification development, and an incentive to do so.

The second reason is that updating the TCK for the latest version of Jakarta EE is a huge undertaking. We’ve got somewhere between one and three million lines of code to verify. That’s, to put it mildly, a lot of work. Ensuring that it’s as easy as possible for the community to contribute will help us get more people working on this task so it can be done in a reasonable amount of time. And the reality is that it’s still going to take a while.

Modern Tools, Streamlined Structure

One of the first and major ways we’re tackling the restructuring of the TCK is making it reliant on more modern tools. So rather than Apache ANT and the Java Test Harness, which were introduced around 20 years ago, we’re integrating Junit 5 and Apache Maven. This way, new contributors to the TCK can work with tools they know how to use, eliminating a significant source of friction.

We’re also streamlining the structure of the TCK itself. There are a lot of great quality-of-life features in the TCK, like the ability to run a TCK test in a graphical user interface. That’s nice to have, but nobody really needs it. And the reality is that these sorts of features increase the internal complexity of the TCK. So, one of the key ways we’re going to make it easier to learn and easier to use the TCK is to eliminate everything that isn’t strictly necessary.

Updating TCK to Multi-Dependency Maven Project

We’ve also been updating the TCK to be a multi-dependency Maven project. This idea came from one of our contributors, Markus Karg. At the time it was kind of a radical idea, but it’s been terrific. We started working on it around the time we were starting on Jakarta EE 10 development, and the plan is to have it finished in time for Jakarta EE 11.

There’s a lot of complexity involved in trying to convert the Apache ANT scripts over, so rather than do that we’ve just been rewriting Apache Maven equivalents. The advantage of this is that the Maven tooling is much higher level than the Apache ANT tooling, which is really a developer tool for building things. In the early days of Java, we were using multiple OS-specific tools because they were the only things available; when Apache Ant came along, it was better so we started using that. But Maven is a further improvement.

Milestone Releases Can Be Tested Against Jakarta EE 10

As with other Jakarta EE releases, we’ll be releasing different component specifications in milestones before the full release of the platform. You can find the whole draft schedule on GitHub. The individual specifications will have their own component TCKs, of course, and then there will be one for the platform itself.

This process also informs how we go about validating Jakarta EE 11 and ensuring that our TCKs are all working. We’ll be making milestone releases available that can be tested against Jakarta EE 10. Because Jakarta EE 10 is already done, it’s really the only way to validate the test kit. If a test doesn’t work, we’ll assume it’s broken but we’ll also try to prove that it’s not while we work on fixing it. That way we’re covering all our bases.

But once we start making Jakarta EE 11 TCK changes, all bets are off. It’s at that point this becomes a very wild process. All the help we can get from the community is important because, like I said before, we’re dealing with millions of lines of code.

Community Contribution Enhances Jakarta’s Utility

Right now, the reality is that the TCKs are a bottleneck for Jakarta EE releases. We just don’t have enough people working on them. And because the TCKs validate specifications, there’s always an opportunity to improve them. Maybe you’ve run into a Jakarta-related bug with a Jakarta EE Specification not being implemented correctly, that’s kind of a pain. Contributing to the TCK to make sure it’s caught by testing is the best way to avoid that in the future.

There was a great trend that happened during Jakarta EE 10, where individual specification teams took over their specification’s TCK. But many other specifications’ TCKs have been built as part of the main platform for a long time, and there’s certainly the opportunity for those teams to take them over.

If you’re one of those teams, it’s as simple as spinning a fork out of the main repo. For everyone in the community who isn’t on one of those teams but wants to help, a good place to start is by joining the TCK mailing list. And when we’ve finished restructuring the TCKs, you’ll be able to find them on the Jakarta EE Platform TCK GitHub page.