Overview

Inspired by #3918 and related discussions, we should consider introducing a mechanism for users to supply arbitrary Java feature versions that are not yet covered by the JRE enum constants.

Note that a "feature" version refers to the leading number in a Java version -- for example, the 21 in 21.0.4. In Java 9, this was referred to as the major number (JEP 223), but the terminology changed to feature in Java 10 (JEP 322).

Deliverables

• Investigate options.
• Revise JRE (via JRE.java.jte) to support feature versions.
• Introduce versions attribute in @EnabledOnJre and revise EnabledOnJreCondition accordingly.
• Introduce versions attribute in @DisabledOnJre and revise DisabledOnJreCondition accordingly.
• Introduce minVersion and maxVersion attributes in @EnabledForJreRange and revise EnabledForJreRangeCondition accordingly.
• Introduce minVersion and maxVersion attributes in @DisabledForJreRange and revise DisbledForJreRangeCondition accordingly.
• Revise EnabledOnJreIntegrationTests, DisabledOnJreIntegrationTests, EnabledOnJreConditionTests, DisabledOnJreConditionTests, etc.
• There are no TODOs left in the code.
• Method preconditions are checked and documented in the method's Javadoc.
• Coding conventions (e.g. for logging) have been followed.
• Change is covered by automated tests including corner cases, errors, and exception handling.
• Public API has Javadoc and @API annotations.
• Change is documented in the User Guide and Release Notes.