Hi,

my clear opinion is to go  with most recent JDK LTS version for the
release point of Maven 4.0.0 which I assume will be JDK 21...

That means clear the build time requirement which is completely
different from runtime of an application.


Older JDK's are supported by some vendors by having particular special
support which most of the time requires special contracts (means also
paying money for it)..some of them offering builds without paying money
yes..

Older runtime target are supported with different approaches like
Toolchain or via `--release XX` which exists since JDK9+.


Furthermore if someone is not capable of upgrading the build environment
to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...

If it would be requirement to port things back to 3.8.X or 3.9.X it
could be handled by someone who has the time etc. to do that ... if not,
those people might think of paying someone to do that work...


The given argument about JPMS for migration causes issues is from my
point of view false-positive because migration to newer JDK versions
does not require JPMS usage...

Even platforms like AWS support JDK17 in the meantime which is the
runtime...


Based on the argument we don't need  features of JDK17+ I see a number
of things which could make our handling/maintenance easier for example
using sealed classes to prevent exposing internal things to public which
could be used etc. also some other small features (`var` for example;
Text-Blocks in Tests etc) or using records in some situation...


Based on the maintenance part it would mean in consequence to downgrade
to even JDK7... (or even lower) because you can get support for older
JDK version in some ways... (JDK7 from azul for example)

Kind regards
Karl Heinz Marbaise

[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to