Hi
Le lun. 5 juin 2023 à 13:22, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > On Sun, Jun 4, 2023 at 10:59 AM Delany <delany.middle...@gmail.com> wrote: > > > > I think the point I'm making is no-one wants to write in an older version > > of the language they started writing in. Its tedious. Anyone who started > > writing java11 code is going to have a hard time accepting they need to > > write in java8, just as a java8 will bulk at writing in java5. Of course > > for the oldies it just feels nostalgic. > > > > Strongly disagree. I personally would strongly prefer to stick to Java > *7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java > 11 were significant downgrades for clarity of code and ease of use. > While there were some nice improvements in libraries and VM in those > versions, they are completely swamped by the truly awful lambda syntax > and the useless pain of the Java Platform Module System. > This is a very interesting feedback cause we had the exact same on some other ASF feedback in early lambdas days and today it is completely gone so I guess it is just a habit thing. So the point is either: do you fight against the scale of time or not and if so is it ok for an asf project to reject potential contributors (because it is what it means in practise, in particular when java 7 becomes hard to get). Note: I fully agree JPMS is useless but I also fully agree we don't need to embrace it, it will not even be enabled until plexus-container does support it, but it does not hurt, rest is more than fine and the new GC helps in a software like maven. > > Nor is it like we've finished the work of migrating onto Java 8. Just > this past week I replaced some code that hasn't been needed since Java > *1.4*. > This is a good point, my personal view on that is we had way too much abstraction for the actual codepath we use so I would be +1 to drop most of the deps we rely on to include a core and limited set in maven project, this will help upgrades instead of having to rely on 50+ projects - indeed just my 2cts. > > Migrating to still newer Java versions is a distraction from far more > important work. We haven't even moved all the plugins off Java 7 yet. > The burden of proof is on people who want to migrate to Java 17 to > show how that will improve the project. That burden has not been met. > Nobody requested to migrate the code base, IMHO the points were mainly: 1. enable to use a "not too old" base version to keep it easy to contribute and leverage interesting new features (note: not always API) 2. use an up to date and evolutive version (java 8 doesnt get all backports these days, even in maintained distro so you can end up accessing a http maven repo which is not supported depending the JVM you use) 3. reduce the compatibility matrix right now since part of it is no more useful for projects which will embrace mvn 4 4. ensure you can upgrade dependencies and do no have to stick to deprecated versions (libs started to drop java 8 support already) So yes Java 17 will not solve most of our issues but Java 8-21 support we need to have already creates some in terms of validations, PR feedback, and community message IMHO. Since java 8 is covered by 3.9 I don't see why we would not take the opportunity to move forward, syntax and details like that are a great opportunity to learn for everybody more than a drawback from my past experience and being able to use a reliable - cause we know it is supported in the min version we use - http11 client with a better protocol support is also important even if API didn't change much. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
