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

• Update Java baseline to 17
• 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