TCK tests are the suite of tests that ensure that distributions of each version of Java are compatible with each other. This testing drastically cuts down on incompatibility issues.

Even if you have a good idea of which versions of Java are running in your organization, working with a vendor who supports more versions will mean you’re prepared if you’re surprised by the results from your application inventory.

In addition to the operating systems and chip sets currently in use in your organization, you’ll want a provider who supports operating systems and architectures that you may want to move to in the future.

Organizations can minimize the risk of an expensive regression by updating to stabilized builds each quarter. These builds are binaries released the previous quarter as Patch Set Updates (PSUs). They’ve been used in production worldwide for three months. Also known as Critical Patch Updates (CPUs), stabilized builds provide security-only fixes — patches for new vulnerabilities reported and fixed during the most recent quarter. These ensure that your Java applications are secure and compliant with internal policies and, depending on your industry, external regulations.

It’s common for large organizations to have departments running on older versions of Java. To remain compliant with internal policies and external regulations, they need a vendor who backports patches for newly reported vulnerabilities. For example, a patch in Long-Term Support (LTS) 17, the current LTS release, may need to be backported to Java Development Kit (JDK) 8, an earlier LTS release that’s reaching the end of its life.

Even leading providers of OpenJDK can find themselves having to delay the release of new quarterly binaries by several days or even sometimes more than a week, often leaving deployments vulnerable to severe vulnerability exploits during the delay window. If the timely release of binaries matters to you, look for a provider with a track record for releasing binaries in under an hour.

Vulnerabilities with the highest scores in the Common Vulnerability Scoring System (that is, those described as “critical”) must be patched right away and may require an out-of-cycle fix. Otherwise, your organization could be exposed for weeks or months. Providers committed to providing critical out-of-cycle fixes will keep your Java applications secure and ensure you stay in compliance.

Over the years, more than 78 vulnerabilities have been reported that affect JavaFX. If you have applications that use components like JavaFX that are not included in OpenJDK, you need a JDK provider who will support those components with JavaFX-configured builds for your JDKs and Java Runtime Environments (JREs).

Patent indemnification protects software users against patent infringement claims. It means that your JDK provider will cover legal costs or damages if a third-party claims you’re infringing on their patents through your use of their JDK.

Similar to patent indemnification, indemnification can protect you in the case of GPL contamination that can result from copyleft licensing. With copyleft licensing, anyone who modifies or distributes the software must make their modification or distribution available under the same license. To prevent this, users of OpenJDK must rely on their provider to protect them by using the Classpath Exception (CPE). Providers who provide indemnification are offering to stand behind their distributions and protect their users from copyleft claims.