Change Java baseline to 17 for 6.0

[marcphilipp]

Motivation

Java 8 is the current baseline of JUnit 5. It was released over 10 years ago and recent versions of Java have introduced many enhancements that make moving to a more recent JDK as the baseline for JUnit alluring. Moreover, there is movement in the ecosystem regarding this issue. For example, Spring has changed their baseline to JDK 17+ with 6.x and free support for 5.x will end in 2024. Similarly, AssertJ will move to Java 17. Therefore, we should consider making a similar move. Doing so would mean bumping the major version number and would allow us to clean up and simplify a number of things. This issue serves as a starting point for collecting those topics and tasks. For users stuck on Java 8 we will extend support for the last 5.x release for at least a year and backport security and important bug fixes to 5.x.

Todos

• Bump JDK baseline to 17 #4249
• Remove deprecated code
• Clean up ConsoleLauncher CLI (remove single-dash long options and mode without subcommand)
• Look for issues labeled with type: breaking change and decide whether they can be addressed in 6.0
• Remove some if not all multi-release JAR code
• Remove separate build task for compiling module descriptors
• Remove any flags that turn on "backward compatibility mode" (e.g. junit.platform.reflection.search.useLegacySemantics) and potentially log a warning if they're used
• Remove @TempDir per context mode?
• Support AutoCloseable instead of CloseableResource in Store?
• Change default behavior for TestInstancePostProcessor and similar extensions wrt. method-level ExtensionContext?
• Adopt new logo (contest?) to remove "5"
• Rename GitHub repo to remove "5"
• Bump Kotlin language version to latest stable
• Discontinue junit-platform-jfr and move listeners to junit-platform-launcher
• Remove ReflectionUtils.isRecord* methods and replace with calls to Class.isRecord()
• Use List.of etc. instead of Collections.emptyList etc.
• Deprecate fail(), assertTrue(boolean), assertFalse(boolean), and similar assertions that do not produce adequate error messages
• Add nullability annotations to public API (use jspecify)
• Replace reflection in JRE.determineCurrentVersion()
• Resolve TODO [#4246] comments within the code base

[jbduncan]

Consider using OpenRewrite's Gradle plugin and Java 17 recipe to find other ways of modernising the codebase.

[mpkorstanje]

Will this also result in a major version change for the JUnit Platform?

[sormuras]

Why (not) upgrade to Java 21?

https://www.java.com/releases/fullmatrix/

• Java 8 was released in 2014
• Java 17 was released in 2021
• Java 21 was released in 2023
• Java 25 will be released in 2025

What's in Java 17 compared to Java 8 (7 years worth of features and bug fixes)?

🤯

What's in Java 21 compared to Java 17 (2 years worth of features and bug fixes)?

• JEP 413: Code Snippets
• JEP 431: Sequenced Collections
• JEP 440: Record Patterns
• JEP 441: Pattern Matching for Switch
• JEP 444: Virtual Threads

See also https://nipafx.dev/road-to-21-upgrade/

[scordio]

Why (not) upgrade to Java 21?

Our strongest argument in AssertJ for targeting Java 17 and not 21 was the compatibility with the Spring Boot generations, as AssertJ is one of the libraries provided by the spring-boot-starter-test.

[sbrannen]

Will this also result in a major version change for the JUnit Platform?

Yes, it will be JUnit 6.

As stated in the issue's description:

Doing so would mean bumping the major version number

[sbrannen]

Why (not) upgrade to Java 21?

Because major players in the Java ecosystem have all gone with Java 17 as the "new baseline" within the ecosystem, while still supporting later versions of Java, and we do not want JUnit to be the odd one out.

[sbrannen]

We will also want to remove any flags that turn on "backward compatibility mode".

For example, we should remove support for the junit.platform.reflection.search.useLegacySemantics configuration parameter.

[scordio]

Although it's a small detail, may I also propose to do #3141 (comment) ?

[marcphilipp]

Will this also result in a major version change for the JUnit Platform?

Yes, it will be JUnit 6.

We intend to change the major versions of the Platform, Jupiter, and Vintage. It's debatable whether Platform should be bumped to 2.0 or 6.0. Doing latter might simplify dependency management and comprehensibility for some. Thoughts?