I would like to kindly remember that this thread is not about the JDK version, if we need such discussion we should start a new thread.
pt., 5 sty 2024 o 18:22 Karl Heinz Marbaise <khmarba...@gmx.de.invalid> napisał(a): > On 05.01.24 17:02, Michael Osipov wrote: > > On 2024/01/05 15:52:54 Karl Heinz Marbaise wrote: > >> ... > >> On 05.01.24 16:19, Michael Osipov wrote: > >>> On 2024/01/05 14:37:44 Karl Heinz Marbaise wrote: > >>>> +1 Also the point JDK11 (maybe even higher JDK17?) for Maven 4.0.0 as > >>>> minimum runtime requirement.. > >>> > >>> This reminds me of https://github.com/openssl/openssl/issues/10902 > and it provides very good reasons why not to do it. Maven is a low level > tool -- as such it has to be available to as many devs as possible. > >> > >> Hm.. I have to admit that I don't see the relationship to OpenSSL and > >> C++ compilers / Perl etc. and which reason do you have in mind? > > > > It is about replacing Perl with CMake. Perl has a much better > availability than CMake... > > And where is the relationship to Maven? Apart from that Perl is not that > available on a lot of systems (the last 10 years have changed that)... > today Python is often more available than Perl... which would bring > CMake back into the game... > > Furthermore not many people are building Curl from sources... I would > say 99% of people consume them via their package manager (dnf, yum, apt > etc.) of their distributions or via flatpak or alike...Who is building > from source today? > > So I don't see here the in relationship to Maven... or are we talking > about bootstrapping Maven from source without pre existing Maven/Ant etc. ? > > > > >> But for Maven 4. I see no problem in upgrading the minimum requirement > >> to JDK 17 (runtime)... If people can not upgrade (for whatever reason) > >> they can continue to use Maven 3.X ... Also as I mentioned several times > >> before even with JDK 17 you can build code for java 7... and if that is > >> not sufficient you can use Toolchain... (also mentioned several times > >> before)... > >> > >> Apart from that if I take that argument in consequence (also mentioned > >> several times before)... than we have to stop any upgrade in JDK minimum > >> version and go back to JDK 1.5 or even 1.4 (or even less)...because > >> there are people using those ancient versions... > > > > Please don't apply our possiblites to others and don't make any > assumptions what others can or cannot do. Rasing to 17 w/o massively > rewriting core to benefit from post-8 constructs a pure lie to ourselves. > We cannot even keep JIRA issue count low. I'd really focus on what really > matters. > > I have given solutions to solve possible issues... and now I should not > show possible solutions... very interesting... > > > Why is massively rewriting required? In Maven core (master branch) is > already using a lot of JDK 8 parts.. which can be increased of course, > for example using JDK17 as base line would make it possible to use > sealed classes, records, var usage etc. only to mention a few... of > course that will take time no doubt about that...(mentioned several > times before)... > > Also staying on old things (JDK8 is old) will not attract new developers > which is a thing in particular in relationship to the mentioned part > about JIRA issues etc. meaning the number of contributors could be > higher... > > Which is from my point of view exactly the opposite argument.. upgrade > to most recent JDK 17 at min ... or even JDK 21... to get better > attraction for other possible contributors.. > > > > > >> https://www.jetbrains.com/lp/devecosystem-2023/java/ > >> https://www.jetbrains.com/lp/devecosystem-2022/java/ > >> https://www.jetbrains.com/lp/devecosystem-2021/java/ > > > > This represents nothing especially not those who aren't or cannot > advertise what thy use. Never trust statistics you haven't falsified > yourself. > > You should check the > https://www.jetbrains.com/lp/devecosystem-2022/methodology/ etc. That's > available for all given reports. You can get the raw data... > > > > not those who aren't or cannot advertise what thy use. > > If they can not use more recent things they can continue to use Maven > 3... (mentioned before).. that contradicts in itself.. described > solutions which work and that should not be shown/mentioned...makes no > sense. > > Those statistics mention things like usage of JDK 7, 6 and even 5. What > is the problem here? Only those reports show that the number of the > usage for JDK5,6,7 is very low...not to say extremely low... > > Based on which argument do you conclude that we can not to upgrade to > JDK 17 or even to JDK 21: for Maven 4? > > 1. It needs time to change things in core > 2. We would exclude people (discussion about how many?) who can not > upgrade. > > > Answers to them: > 1. It has taken time to incorporate changes for JDK 8 in core and > plugins etc.. and it will take time to change more of course.. no doubt > about that. > 2. Mentioned solutions for that. (continue to use Maven 3.X; Toolchain). > > Are those things a reason not to lift ? No. > > Furthermore So that means your own arguments are now contradicted... > > Many other tools and libraries and frameworks already did that (Spring > Boot 3(JDK 17), Quarkus(JDK 17), Micronaut (JDK 17) etc., ..... and even > Jakarta EE 11 has set even JDK 21 as baseline... > (https://jakarta.ee/specifications/platform/11/) > > > Kind regards > Karl Heinz Marbaise > > > > > > M > > > > --------------------------------------------------------------------- > > 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 > > -- Sławomir Jaranowski
