Re: Let's move Surefire project to JAVA 9. Surefire and Failsafe stop working on latest versions of Windows due to missing wmic.

> Op 11 feb 2026 om 16:27 heeft Thorsten Heit <[email protected]> het volgende geschreven:
> 
> Hi,
> 
>> One more time: please don't confuse the Oracle Java support map with
>> Java support. They are not the same thing. Java has had multiple
>> vendors for almost 20 years. What Oracle will support is only what
>> Oracle will support. I wouldn't even consider Oracle the primary
>> vendor of Java any more.  IBM, Azul, Amazon, Microsoft, Red Hat, the
>> OpenJDK Project, and others have significantly different schedules.
>> A quick search does show Azul and Amazon ending support for Java 8 on
>> January 1 2031 so 2030 is probably about the right time for us to
>> consider dropping Java 8 support.

Waiting until the last commercial support vendor stops their (typically expensive) extended support offering of Java 8 would in my opinion not be the right approach.

>> I wouldn't do it before then. There
>> are practical advantages to sticking on Java 8 that still outweigh the
>> advantages of upgrading for some shops.
> 
> Correct, but personally I can't imagine having a good reason to still restrict your codebase on Java 8 at the end of 2030, more than 16 years after that version was released, when
> * there's Java 35 available (if I counted correctly and they're still using a 6-month release cycle)
> * lots of LTS versions got released in the meantime until then (actually we got four: 11, 17, 21 and 25).
> 

With the de facto frameworks of the Java enterprise eco-system (Spring Framework and Jakarta EE) having moved the low watermark of Java SE versions supported beyond 8 (Jakarta EE 10 to Java 11+, Spring 6/Jakarta EE 11 to Java 17+) I'd say it would be a fine time to also put Java 8 support in Surefire to an end (or into a dormant critical security-fixes only mode) and raise the bar for current Surefire releases to newer Java SE releases.

All java releases up to now are still able to produce Java 8 bytecode if companies don't want to switch their production runtime - they just need to ensure that their codebase is not violating the implicit boundaries of the JVM internals that have since been shielded off to enable Surefire to run tests on Java 11 or later.

Keeping Java 11 support in surefire would be nice as that would help in getting bad Java 8 code (crossing the informal boundaries of the JVM internals) upgraded incrementally from one LTS to the other (benefitting from the typically 1 LTS version only JVM flags that on an opt-in basis re-allow the boundary crossing) until all usages of now shielded off internals are removed from an application and it can nicely run on the latest LTS release.