Perso I do not have any issue using 17. By curiosity, I wonder what sort of 17 (or 9+) features we really want/need? Pattern matching for switch? record (so we can get rid of Modello but record will be not compatible with previous standard beans).
On Fri, 2 Jun 2023 at 09:17, David Jencks <david.a.jen...@gmail.com> wrote: > > I wonder if having maven require java 8 syntax discourages any potential > contributors who are used to coding using more recent developments. I have no > idea how to tell, but maybe someone else does. > > David Jencks > > > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > > > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
