Certified, compliant, compatible – all these terms are used to describe whether a JVM fits the Java standard. What’s the difference and why does it matter for your apps?
Java versions, in all their variants (SE, ME, EE, etc.) are standards controlled by the Java Community Process (JCP). The Java Technology Compatibility Kit (TCK or JCK) is an extensive test suite created for each Java release that ensures that a Java Virtual Machine implementation (JVM) meets the standard. If a JVM doesn’t fully meet the standard, you could find that your application runs well on one JVM but has problems on another. For example, certain function calls may not work as expected. Testing a JVM against the TCK ensures uniformity and portability. Switching from one JVM to another that both meet the same TCK is completely seamless.
Going back to our compliance terms, what do they mean relative to the Java standard and the TCK? The words ‘compatible’ and ‘compliant’ carry meaning relative to the Java standard. Things that did not pass the TCK/JCK tests cannot claim compatibility or compliance with the Java SE specifications. Only binaries that had the tests performed can make that claim (which unfortunately doesn’t stop some providers from claiming compliance anyway). Without exhaustive testing, as we all know, the JVM may or may not meet every aspect of the standard. A few things might have been missed or might not work as intended. Only by fully testing every aspect of the JVM can anyone ensure full compliance with the standard.
But surely the JVM binaries I can download on the web are compliance tested, right? Well, no. Many of them are not. Only a few firms license the TCK and use it for testing. You can find the list here.
A good example of ‘buyer beware’ is one of the official Dockerfiles for Java. They’ve posted one for Java OpenJDK 8u40, which won’t be released until March of 2015! 8u40 is still under development, and it’s a moving target. Do you really want to deploy a production app on it? The TCK isn’t even available yet, so you know it hasn’t been tested.
When you use OpenJDK™, it’s worth noting that the project does not provide binaries, only sources. So whatever binaries you end up deploying will be provided by someone else. They do not come from Oracle or the OpenJDK project. These binaries will either closely follow the released OpenJDK contents and be diligently tested, as Azul Zing and Azul Zulu do, or they won’t.
What does this mean? Zulu is a binary build of OpenJDK, but more importantly, Zulu 8 is a binary build of OpenJDK 8 that has been tested against the Java SE 8 TCK, and certified as compatible with the Java SE spec. Your apps built for Java SE 8 will run seamlessly on Zulu, and you can switch from another tested compliant JVM to Zulu without worry.
So Zulu is much more than a “compatible” binary, or a “variant” of OpenJDK. Currently, Zulu is the only fully tested OpenJDK 8 binary build available. Zulu does not vary from OpenJDK. Instead, it is a CERTIFIED COMPATIBLE and COMPLIANT binary builds of OpenJDK 8, 7, and 6, CERTIFIED by Azul that the Zulu binary was actually tested and that Azul stands behind it.
Why would you trust your Java applications to anything else? You can download these certified builds of Azul Zulu (they’re free) from our website.
