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

[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?

[sbrannen]

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?

It would definitely simplify things for people and tools.

Changing Vintage to align with Jupiter had positive side effects, and moving all 3 submodules to the same version number would take that a step farther.

So, I think I'm in favor of 3 * 6.0 for Platform, Jupiter, and Vintage.

[marcphilipp]

For everything where we intend to change the default behavior (e.g. the Locale parsing suggested above), I think there should be an opt-in configuration parameter for the new behavior and a deprecation warning of some form if the old behavior is being used – both in a 5.x release. In 6.0 the configuration parameter can them be removed as it has become defunct. For some features this is already in place. For others we'll have to add it for 5.12 (or 5.13 if necessary).

[armandino]

Would it make sense to skip version 6 and go straight to JUnit 7?

The alignment of Java 17 and JUnit 7 creates a simple association for users.

[sormuras]

If we skipped some versions, we should target JUnit 17 right away.

[Bukama]

Would it make sense to skip version 6 and go straight to JUnit 7?

The alignment of Java 17 and JUnit 7 creates a simple association for users.

I personally don't create a association between that.

[mpkorstanje]

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?

Changing Vintage to align with Jupiter had positive side effects, and moving all 3 submodules to the same version number would take that a step farther.

It depends I suppose.

Unlike Vintage, the JUnit Platform is not user facing. And tools using the JUnit platform have a comparatively slow development pace. So there is value in being able to communicate that there are no breaking changes in the Platform, even if there are in JUnit.

Though if you do not expect to make breaking changes to JUnit without also making breaking changes to the Platform then it doesn't matter and keeping the version numbers synced would simplify things.

[marcphilipp]

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.

Added to the task list in the issue description. 👍

[sbrannen]

Unlike Vintage, the JUnit Platform is not user facing. And tools using the JUnit platform have a comparatively slow development pace. So there is value in being able to communicate that there are no breaking changes in the Platform, even if there are in JUnit.

The thing is: we have never released JUnit Jupiter without releasing the Platform (and bumping its version number) along with it, even if there were no changes to the Platform JARs.

We originally thought that we may at some point release them out of sync, but ever since JUnit 5.0 GA we have never done that.

In addition, we sometimes make changes to the Platform (for example changes in ReflectionUtils in "commons") that are required by Jupiter and/or Vintage. So, they effectively have to be in sync, and consequently tools have to take that into account.

In summary, having different version numbers for the Platform and Jupiter/Vintage seems to cause more problems than it was intended to solve.

[Bukama]

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

Yes, it will be JUnit 6.

Might be a strange question, but I mean it really serious. And the answer might also affect the JUnit Pioneer extension library.

The user guide says

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

In this ticket you speak of JUnit 6 so the left part of this "equation". You also noticed that you want to raise versions of platform and vintage (so I guess you keep the names).

I'm confused about Jupiter, because I have in mind that it's named after the fifth planet of earth's solar system. Will this part of JUnit renamed to Saturn? Where will this lead with JUnit 9+?

Why it affects JUnit Pioneer? Because Pioneer 10 was the first space probe that flew close to Jupiter...

[sbrannen]

The user guide says

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

In this ticket you speak of JUnit 6 so the left part of this "equation". You also noticed that you want to raise versions of platform and vintage (so I guess you keep the names).

Yes, we will keep the names.

We chose "names" over version "numbers" on purpose: to ensure that we don't have any issues with package or type names when we release a new generation or JUnit.

For example, we originally had junit5 in the package names and decided that would look horrible if we released JUnit 6 with junit5 package names. That's why we spent a lot of time coming up with the Platform, Jupiter, an Vintage module names.

So, for JUnit 6, we are currently considering aligning all 3 versions as follows.

JUnit 6.0 = JUnit Platform 6.0 + JUnit Jupiter 6.0 + JUnit Vintage 6.0

I'm confused about Jupiter, because I have in mind that it's named after the fifth planet of earth's solar system.

Indeed, we did pick "Jupiter" for JUnit 5, because it starts with "Ju" and is the 5th planet from our sun.

Will this part of JUnit renamed to Saturn?

No.

Where will this lead with JUnit 9+?

I don't know if I'll even still be alive by that point in time, and I cannot predict the (potentially) distant future. 😇

But the plan is to keep using the Jupiter and Vintage module names as long as it makes sense.

Why it affects JUnit Pioneer? Because Pioneer 10 was the first space probe that flew close to Jupiter...

🚀