Hi,
Yes JDK8 is supported till 2030 but it looks like undefined in the table below. I don't consider this as a healthy argument that we should be on Java 8 as well especially if it is the year 2030 because then we are affected by this decision for years. The Maven 4 goes with Java 17 - I am glad. See this table: https://www.oracle.com/java/technologies/java-se-support-roadmap.htmlIf somebody understands this problem and especially the Surefire project then he must realize that we are talking only about *Forked-JVM problem*. a not the *In-Process* (means in-maven JVM execution). That's a big difference because then we can split the decision in two: *1. Maven plugin itself on Java 8 including the In-Process Provider, and* *2. Forked-JVM on Java 9. This is not in contrast with the decision that all Maven 3.x and plugins are on Java 8.* Additionally, in practice you have the projects compiled by Java 8 compiler but the runtime is at higher version and the reason is JVM performance. If this is still not such case in some projects, then we should keep the code as it is because it has polymorphism and the implementation was designed to be extensible. This means that we can stick to the *WMIC* command and switch to *ProcessHandle.isAlive() *if Java 9+ presents or if the *WMIC* is not found, and this is I think a good compromise for everyone. WDYT?
If you think about a new release, why not upgrading the corresponding codebase to at least Java 17 (better: 21) to stay in sync with the upcoming Maven 4? This won't prevent users from still coding against Java 8, but can make the project's life much easier.
Just my 2ct Thorsten
OpenPGP_0x5A54BBB878225E08.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
