Jakarta EE means IT investment stability. The pillars of this stability are time and compatibility.
Let's take time. Enterprises need stability measured in many years, in the face of a highly volatile product marketplace. But if you continually evolve a product over many years, it is extremely important to manage technical debt. Technical debt is what happens when you must decide between doing "the right thing" and "the quick thing" and you choose the latter. On a huge product like Jakarta EE, there are hundreds of such decisions in all parts of the product, taken over the multiple decades development. For the specifications, we skew heavily towards doing the right thing. For other aspects of the product, the skew is more balanced. This is where compatibility testing enters the discussion. Jakarta EE asserts compatibility across vendor implementations using the Test and Compatibility Kit (TCK). The TCK is a very complicated software tool that itself is subject to accruing technical debt. However, because the nature of the TCK is to assert compatibility of features rather than to help invent and bring new features to market, the problem of technical debt in the TCK is even more acute. Over the decades of development, the infrastructure of the TCK has more often been compelled to choose the quick thing. Jakarta EE 11 is where the buck stops.
During Jakarta EE 11, the platform project team endorsed and embraced the Platform TCK team's recommendation to pay down the technical debt that has been accruing in the TCK for over two decades. This technical debt has made the platform TCK nearly impossible to maintain and evolve. After decades of technical debt, the Platform TCK represented a huge barrier to innovation in Jakarta EE. The learning curve for adding new tests required mastery of bespoke testing technologies that predate current tools and practices. Our plan is to refactor the Platform TCK using current testing tools and practices and make it much easier to run and author tests. Red Hat has contributed the innovative engineering work, with vital contributions from Oracle, OmniFish, and other community members. The Platform TCK refactoring effort has introduced delays in the delivery schedule for Jakarta EE 11, but we judge it worthwhile to enable continued innovation and development.
The Jakarta EE Platform TCK is a vital software component for delivering the value proposition of IT investment stability on the scale of decades. The software of the TCK has been accruing technical debt due to lack of maintenance investment. This technical debt has made the platform TCK nearly impossible to maintain and evolve. After decades of technical debt, the Platform TCK represented a huge barrier to innovation in Jakarta EE. In Jakarta EE 11 we are bringing the TCK up to date with the state of the art of testing tools. This investment will enable better compatibility testing and lower the barrier to adding more tests as the Jakarta EE platform evolves.
NBD, but I think the "This technical debt has made the platform TCK nearly impossible to maintain and evolve. After decades of technical debt, the Platform TCK represented a huge barrier to innovation in Jakarta EE." sentences are good in the Short version as well. They clearly state the key point, and they don't make it not short.