Deprecate unsupported JRE enum constants and update related conditions

[marcphilipp]

• Remove unnecessary reflection in JRE enum
• Deprecate JRE.JAVA_8...JAVA_16
• Change default min of @EnabledForJreRange and @DisabledForJreRange to JRE.JAVA_17

Overview

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• 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

[sbrannen]

Thanks for putting together this PR!

I've left some comments for discussion...

[sbrannen]

I don't think we can do that, since that would break existing code.

In other words, deprecating the unsupported enum constants should suffice: people will see the warnings and update their code accordingly. But... existing code should not break.

For example, @EnabledForJreRange(min = JAVA_9, max = JAVA_21) should still logically work with a Java 17 baseline, and the deprecation of JAVA_9 will encourage the user to migrate that declaration to @EnabledForJreRange(min = JAVA_17, max = JAVA_21).

[marcphilipp]

I don't think we can do that, since that would break existing code.

I had a softer validation mode at first where it would only fail if the range contains no version that is no longer supported at runtime (e.g. 9-11).

For example, @EnabledForJreRange(min = JAVA_9, max = JAVA_21) should still logically work with a Java 17 baseline, and the deprecation of JAVA_9 will encourage the user to migrate that declaration to @EnabledForJreRange(min = JAVA_17, max = JAVA_21).

The deprecation only applies for the JRE enum constants. If integers are used, there will be no deprecation warning. For example, @EnabledForJreRange(minVersion = 9, maxVersion = 11) will not produce a compiler warning. The test, however, will never be executed because 17 is the minimum runtime version.

I think it would be acceptable to break some existing tests (at runtime) when users upgrade to 6.0. It's better than the alternative of tests always being skipped going unnoticed. We could relax the validation to only fail if a range contains no supported runtime version (so 9-21 would be allowed because contains 17-21). That would still break some tests but fewer.

[marcphilipp]

We could make the strictness of the validation configurable via a configuration parameter... 🤔

[sbrannen]

We could relax the validation to only fail if a range contains no supported runtime version (so 9-21 would be allowed because contains 17-21).

Yes, let's do that.

If we can determine that the range is now obsolete, throw an exception.

If we can determine that the range is still valid (even if too broad), do not throw an exception.

[sbrannen]

We could make the strictness of the validation configurable via a configuration parameter... 🤔

Mmmm... yeah, we could do that, but I'd rather avoid too many behavioral configuration flags if possible.

Maybe we should just see how the community reacts to "rejection of no longer applicable ranges".

[marcphilipp]

I've removed the strict check again and decided against the additional validation mainly because we already have tests in place that use @DisabledOnJre with all defined JRE enum constants (except JRE.UNDEFINED) and verify that the test is skipped.