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
