+1 I really don't what benefit we get from going to Java 17
I perfectly see the impact we'll have on our users: for what benefit? notice that this will also impact all plugins: and given the few work done on plugins to clearly show what plugin version remains compatible with a JDK release, I feel we're not taking the topic the right way Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit : > I'm not sure I would worry too much about that David. I think most devs > who want better syntax moved from Java sometime ago. They might still be > on the JVM just not writing Java. Also, Maven is a mature project. I > don't think devs considering contributing to it are thinking about using > the latest and greatest version of Java. Compatibility is probably a > bigger concern for the user base. Just my opinion. > > Hunter > On Thursday, June 1, 2023 at 04:17:26 PM PDT, 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
