> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
