Opportunities to Improve the Jakarta EE Platform TCK

The Eclipse Jakarta EE Technology Compatibility Kit (TCK) team needs your help. We’re creating more opportunities for the Jakarta EE community to help develop Jakarta EE platform TCK tests. We need to do this because as we add new technologies to Jakarta EE, we also have to add the appropriate tests to prove the technologies are correctly implemented in Jakarta EE releases and server implementations.

Before I explain how you can get involved in developing TCK tests, here’s a brief overview of why they’re so important to the future of Jakarta EE.

Platform and Standalone TCK Tests Must Be Passed

Every Jakarta EE server implementation must pass 100 percent of the platform TCK tests. The TCK tests prove the server is compatible with the Jakarta EE specification requirements.

Every Jakarta EE server implementation must also pass standalone TCK tests. Generally, these tests are focused on a specific Jakarta API, such as the Jakarta Contexts and Dependency Injection standalone TCK, while the platform TCK tests ensure all Jakarta EE specifications (technologies) work correctly when called from various Jakarta EE containers/technologies.

Jakarta EE Platform TCK Tests Verify Compatibility Levels

The Jakarta EE platform TCK tests verify the level of compatibility applications can expect for each Jakarta EE specification technology. This testing of expected behavior increases application portability to different Jakarta EE server implementations.

For example, some TCK tests invoke Jakarta Persistence persistence contexts through remote session bean calls where a different Java virtual machine (JVM) thread may be used for every call. This can create conditions that are similar to those your applications may be using and make it easier to discover edge cases that can only be reached when testing with a Jakarta EE server implementation. This approach has helped me find problems during TCK testing that I might not have discovered as quickly. Applications will reach the edge cases eventually, but it’s better to discover them as early as possible.

The roughly five million lines of TCK test code cover many different situations, each of which offers value to the applications that deploy on Jakarta EE server implementations. If the TCKs were not used to test the Jakarta EE specifications, application developers may be caught in situations where an application server is not fully implementing some aspect of the Jakarta EE specifications. And that’s why we need your help.

Get Involved in TCK Test Development

To start participating in TCK test development, follow the steps below.

1. Join the jakartaee-tck-dev mailing list to start participating in TCK conversations and voice your opinions.

It’s perfectly fine to ask how you can help or what’s new this week. We have fewer than 100 subscribers on this mailing list, which means we’re missing you, so please join. After Jakarta EE 9 is released, we’ll take a moment to introduce ourselves on the Platform TCK mailing list and celebrate the release. We can also start discussing changes you can help with.

One challenge is that we need to document the internal workings of the TCK. We can start asking questions and adding answers to the wiki for all to learn from. Here are some instructions for contributing to a wiki that may help us make remote changes to the wiki. The wiki is a work in progress. If it doesn’t help, we’ll find a different way to document TCK questions and answers.

2. The easiest way to get started is to git fork a Jakarta EE git repository. To do this, go to github.com/eclipse-ee4j/jakartaee-tck, then click on Watch, Star, and Fork near the top right of the browser screen:

3. Set up a copy of your forked jakartaee-tck repository using the git clone command: git@github.com:YourGitHubID/jakartaee-tck.git. Progress will be indicated as shown in the example below:

  • Cloning into 'jakartaee-tck'...
  • remote: Enumerating objects: 4, done.
  • remote: Counting objects: 100% (4/4), done.
  • remote: Compressing objects: 100% (4/4), done.
  • remote: Total 92888 (delta 0), reused 1 (delta 0), pack-reused 92884
  • Receiving objects: 100% (92888/92888), 59.82 MiB | 27.20 MiB/s, done.
  • Resolving deltas: 100% (71537/71537), done.

4. Join other Jakarta EE mailing lists so you can monitor and participate in the discussions.

For example, if you subscribe to jpa-dev, you can participate in developing the Jakarta Persistence specification. You can also participate in discussions about new APIs and voice concerns about issues with current APIs.

5. Look for other Jakarta EE git repositories you can contribute to:

  • Go to github.com/eclipse-ee4j.
  • Click Star on the projects you like.
  • Fork the projects you would like to contribute to. We have a lot of documentation, code, and scripts that need your help.

6. Sign the Eclipse Contributor Agreement with the same email address you use for GitHub:

Go to eclipse.org/legal/ECA.php and read the agreement.

Click the ECA form link.

When making changes locally to your fork of a GitHub repository, be sure to sign all git commits. For example: git commit -s -a -m"add new test for Jakarta Persistence transaction timeout handling".

If You Only Do One Thing

Remember to join the Jakarta EE Platform TCK mailing list and other Jakarta EE mailing lists so you can ask questions, follow, and participate in the future development of Jakarta EE.

About the Author

Scott Marlow

Scott Marlow

Scott Marlow is principal software engineer of the WildFly/JBoss Enterprise Application Platform team at Red Hat and is the Jakarta EE Platform TCK Project Lead.