Because maintaining Java 7 is a barrier to new contributors. It is tricky enough to get Java 8 set up for some developers. Every version we support adds complexity for contributors. Personally, I think we should be thinking about dropping even Java 8 if we wait until next year and just follow the latest LTS line... but I am happy to keep with Java 8 as a baseline for now. Java 7 is only supported for a limited number of environments right now, whereas Java 8 has multiple vendors supporting it against multiple platforms at least until mid 2023.
We hold back the entire community if we stick on a base version for too long. On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote: > Why not have 3.7.0 plugin updates and other non-technical stuff, have it > parallely maintained for some time and move with Maven 3.8.0 to Java 8 > next year?! > > Does that sound like a plan? I'd be happy with that. I'd also expect > an announcement on dev@, announce@ and users@. > > Michael > > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr > > Von: "Stephen Connolly" <stephen.alan.conno...@gmail.com> > > An: "Maven Developers List" <dev@maven.apache.org> > > Betreff: Re: [DISCUSS] Maven 3.7.0 > > > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > We already have a version policy: > > > > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy > > > > > > > (while that page says draft, the proposal was on-list in 2014 and just > > converted into a wiki page afterwards - hence why the examples use 2014 > > dates) > > > > > > > > The development line of Maven core should require a minimum JRE > version > > > that is no older than 18 months after the end of Oracle's public > updates > > > for that JRE version at the time that the first version of the > development > > > line was released, but may require a higher minimum JRE version if > other > > > requirements dictate a higher JRE version. > > > > > > End of public updates for Java 8 from Oracle was January 2019, thus if > we > > > cut a new minor version we would be Java 8 but not Java 7. > > > > > > > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <tibordig...@apache.org> > wrote: > > > > > >> Stephen, we are in loop. > > >> Of course I know these technical things. > > >> But I am saying, and I am not alone (Michael Osipov too), that I agree > > >> with > > >> sources 1.8, but there must be1. the Vote with milestones regarding > Maven > > >> and another Vote regarding plugins, and 2. written list of pros/cons > > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants, > > >> another professions as well in the team). > > >> You know, with video calls, all these public emails would be gone > within > > >> one or two hours, I am sure! > > >> I am also sure that we will have another code preferences and > therefore we > > >> should have some guideline. For instance, I like to have clear OOP in > the > > >> public class/interfaces and Lambda in private code. And there are a > lot of > > >> stuff, like parallel streams ala thread pool of non-daemon threads, > > >> performance of streams (when, how stream is constructed, etc), Date > Time > > >> API is new as well. > > >> > > >> No benefit for the community with J7 sources but yes with J8 code. > Believe > > >> me, this is true. Michael mentioned that as well. > > >> > > > > > > Not true. Java 8 bytecode adds additional metadata that speeds up > > > classloading (but only when the class graph is all Java 8) > > > > > > > > >> > > >> It is also true that we have a lot of bugs, and it is true that Maven > > >> needs > > >> to have breakthrough features like reproducible build and User POM, > Docker > > >> prefetched cache, etc. > > >> I have no argument against these things. The only problem that I have > and > > >> Michael has is the way how this is managed but it is the only trivial > > >> problem that we can solve between us. > > >> > > >> > > >> > > >> > > >> > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly < > > >> stephen.alan.conno...@gmail.com> wrote: > > >> > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the > Java 8's > > >> > javac. > > >> > > > >> > -target must be >= -source > > >> > > > >> > So to say: > > >> > > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code! > > >> > > > >> > Is not possible, you'll get something like: > > >> > > > >> > $ javac Test -source 1.8 -target 1.7 > > >> > javac: source release 1.8 requires target release 1.8 > > >> > > > >> > While we could use something like > > >> https://github.com/luontola/retrolambda > > >> > its usage is not without significant risks. You really need to be > very > > >> > careful in how you use it, and the effort is IMHO far exceeding the > > >> risk. > > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be > Java > > >> 8+, > > >> > use toolchains if you need to compile or unit tests with older JDKs. > > >> > > > >> > We have agreed before that upgrading the Maven minor or major > version > > >> would > > >> > affect the JREs that Maven can run on. Basically following a one > and one > > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be > > >> forced > > >> > to Java 8 as minimum anyway.... in other words, our users should be > > >> > expecting us to go Java 8 as baseline. > > >> > > > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <tibordig...@apache.org> > > >> wrote: > > >> > > > >> > > Stephen, what issue with current toolchain you mean? > > >> > > > > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly < > > >> > > stephen.alan.conno...@gmail.com> wrote: > > >> > > > > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana < > tibordig...@apache.org> > > >> > > wrote: > > >> > > > > > >> > > > > Robert, I saw the code. The class has a method which returns > > >> Lambda > > >> > > > > function. The whole class was designed with OOP. The OOP is a > good > > >> > > thing > > >> > > > > which you should follow and follow this approach and not to > return > > >> > the > > >> > > > > labda function. Basically it is a precedense created in the PR > > >> saying > > >> > > > that > > >> > > > > now J8 has to be used in the bytecode. > > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source > code! > > >> > > > > > > >> > > > > > >> > > > That is not possible using the current toolchains. Let's just go > > >> with > > >> > > Java > > >> > > > 8. There seems no good reason to hold back > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte < > > >> rfscho...@apache.org > > >> > > > > >> > > > > wrote: > > >> > > > > > > >> > > > > > The outcome is quite clear to me. There no clear 'No' to add > > >> this > > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which > > >> implies we > > >> > > > must > > >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures. > > >> > > > > > > > >> > > > > > But first we need to deliver a 3.6.3 regression release. > > >> > > > > > > > >> > > > > > Robert > > >> > > > > > > > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau < > > >> rmannibu...@gmail.com> > > >> > > > > wrote: > > >> > > > > > +1, the risk is more or less 0 since we can still use > branches > > >> for > > >> > > > > > potential fixes for "old" projects using frozen java and > maven > > >> > > versions > > >> > > > > > anyway > > >> > > > > > > > >> > > > > > Guess we can even be very precautionous doing 1. an upgrade > to > > >> > > bytecode > > >> > > > > > version without any code change (to change the major > version in > > >> > > > > bytecode), > > >> > > > > > 2. a M1 to let users test it if some still doubt. > > >> > > > > > > > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit : > > >> > > > > > > > >> > > > > > > so what is the status of this? > > >> > > > > > > will we discuss in 2025 about being able to use java 8 > apis > > >> or do > > >> > > we > > >> > > > > have > > >> > > > > > > to wait 2030? > > >> > > > > > > Sorry to be sarcastic but not moving forward it's > certainly a > > >> > > reason > > >> > > > > why > > >> > > > > > we > > >> > > > > > > do not have more people participating in the project.... > > >> > > > > > > It is so frustrating to be stuck with old apis... > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote: > > >> > > > > > > > > >> > > > > > > > I have to fully agree on Michael Osipov. This > discussion is > > >> > > > > > > > contraproductive from the time perspective. > > >> > > > > > > > He explained the situation in Maven very clearly that we > > >> have > > >> > > over > > >> > > > > 1800 > > >> > > > > > > > bugs and here we are talking about javac compiler > version > > >> which > > >> > > > does > > >> > > > > > not > > >> > > > > > > > fix these bugs. > > >> > > > > > > > We know that our community is quite big but we also know > > >> that > > >> > we > > >> > > > have > > >> > > > > > > only > > >> > > > > > > > few several developers who regularily provides fixes > for the > > >> > bug > > >> > > > and > > >> > > > > > they > > >> > > > > > > > do it for free! > > >> > > > > > > > So my advice is to leave these talks alone about > technology > > >> > lobby > > >> > > > > (seen > > >> > > > > > > on > > >> > > > > > > > ML from outside as well) and rather concentrate on the > bug. > > >> We > > >> > > have > > >> > > > > > seen > > >> > > > > > > > that the users/contributors handled performance issues > and > > >> > fixed > > >> > > > them > > >> > > > > > > which > > >> > > > > > > > means that these contributors got very good proficiency > > >> level! > > >> > > > > > > > > > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <> > > >> > > > > > > ashitkin.a...@gmail.com > > >> > > > > > > > > > > >> > > > > > > > wrote: > > >> > > > > > > > > > >> > > > > > > > > Totally disagree on the point. Writing java7 code > after 8 > > >> > makes > > >> > > > you > > >> > > > > > > feel > > >> > > > > > > > > suffering - because instead of expressive stream based > > >> > > operations > > >> > > > > and > > >> > > > > > > > > lambdas you write pointless iterators and copy > > >> collections. > > >> > > > > > > > > It is purely subjective opinion that lambdas make code > > >> less > > >> > > > > readable > > >> > > > > > - > > >> > > > > > > at > > >> > > > > > > > > least there is an absolutely opposite opinion > > >> > > > > > > > > > > >> > > > > > > > > Thank you > > >> > > > > > > > > Aleks > > >> > > > > > > > > > > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote: > > >> > > > > > > > > > Who codes for 18 months before discovering that > qa/prod > > >> are > > >> > > not > > >> > > > > > > > > compatible, > > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom > > >> starter. > > >> > > > > > > > > > > > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty > Harold <> > > >> > > > > > > > elh...@ibiblio.org > > >> > > > > > > > > > > > >> > > > > > > > > > wrote: > > >> > > > > > > > > > > > >> > > > > > > > > > > Theoretically that would work. In practice though, > > >> every > > >> > > > > project > > >> > > > > > > I've > > >> > > > > > > > > > > seen convert to Java 8 rapidly starts adding > lambdas > > >> that > > >> > > > make > > >> > > > > > the > > >> > > > > > > > > > > code more obfuscated for no good reason and soon > > >> > introduces > > >> > > > > hard > > >> > > > > > > > > > > dependencies on Java 8, intentionally or > otherwise. > > >> At a > > >> > > bare > > >> > > > > > > > minimum, > > >> > > > > > > > > > > a CI environment that runs Java 7 is required. > > >> > > > > > > > > > > > > >> > > > > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant > > >> > > > > > > > wrote: > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > Would jdk 8 for maven itself and a target of 7 > for > > >> the > > >> > > > > compiler > > >> > > > > > > > > (etc) for > > >> > > > > > > > > > > > maven-using projects be ok? > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty > > >> Harold <> > > >> > > > > > > > > elh...@ibiblio.org > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > wrote: > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > Strong -1 on Java 8 as the minimum version. > Google > > >> > > Cloud > > >> > > > > > > Platform > > >> > > > > > > > > has > > >> > > > > > > > > > > > > lots of products and customers that still > require > > >> > Java > > >> > > 7. > > >> > > > > If > > >> > > > > > > > Maven > > >> > > > > > > > > > > > > requires Java 8, we'd have to stick to the > latest > > >> of > > >> > > > > > whichever > > >> > > > > > > > > release > > >> > > > > > > > > > > > > does support Java 7 for at least a year and > I'm > > >> > > guessing > > >> > > > > > > longer. > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert > Scholte <> > > >> > > > > > > > > rfscho...@apache.org> > > >> > > > > > > > > > > > > wrote: > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > Hi, > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > TLDR; introduce > maven.experimental.buildconsumer > > >> > and > > >> > > > push > > >> > > > > > > Java > > >> > > > > > > > > > > > > requirement > > >> > > > > > > > > > > > > > to Java 8 > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > now that Maven 3.6.2 is out for a couple of > > >> weeks, > > >> > it > > >> > > > > seems > > >> > > > > > > > like > > >> > > > > > > > > we > > >> > > > > > > > > > > > > didn't > > >> > > > > > > > > > > > > > face real regressions. > > >> > > > > > > > > > > > > > The only one might be tricky is the issue > > >> related > > >> > to > > >> > > > > Tycho. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > However, I think we're ready to push Maven > to > > >> the > > >> > > next > > >> > > > > > level. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > For those actively reading this list, they > > >> should > > >> > > > > recognize > > >> > > > > > > the > > >> > > > > > > > > need > > >> > > > > > > > > > > for > > >> > > > > > > > > > > > > > splitting up the pom as it is on the local > > >> system > > >> > > > versus > > >> > > > > > the > > >> > > > > > > > pom > > >> > > > > > > > > > > being > > >> > > > > > > > > > > > > > uploaded. Once we truly control this > mechanism > > >> we > > >> > can > > >> > > > > think > > >> > > > > > > of > > >> > > > > > > > > > > > > > improvements on model 5.0.0 and new > fileformats. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > I've created and implemented MNG-6656[1]. It > > >> also > > >> > > > > contains > > >> > > > > > a > > >> > > > > > > > zip > > >> > > > > > > > > > > with an > > >> > > > > > > > > > > > > > example (original, patched, README) to > > >> understand > > >> > > > what's > > >> > > > > > > > > happening. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > In order to make this successful, we need > IDEs > > >> and > > >> > CI > > >> > > > > > Servers > > >> > > > > > > > to > > >> > > > > > > > > > > > > > understand and support these changes. The > likely > > >> > need > > >> > > > to > > >> > > > > > > > > implement > > >> > > > > > > > > > > one of > > >> > > > > > > > > > > > > > the interfaces[2]. > > >> > > > > > > > > > > > > > The new interface uses Java8 Functions (and > > >> > > especially > > >> > > > > > > > > > > SAXEventFactory is > > >> > > > > > > > > > > > > > way easier to read+maintain with Java 8). > I've > > >> > tried > > >> > > to > > >> > > > > > keep > > >> > > > > > > > > Maven > > >> > > > > > > > > > > Java 7 > > >> > > > > > > > > > > > > > compatible, but that was too hard to do. > > >> > > > > > > > > > > > > > So I'd like to use this opportunity to move > > >> Maven > > >> > > > forward > > >> > > > > > and > > >> > > > > > > > > start > > >> > > > > > > > > > > > > > requiring Java 8. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > There are some other improvements I'd like > to > > >> add > > >> > > > (those > > >> > > > > > > > messages > > >> > > > > > > > > > > will > > >> > > > > > > > > > > > > > follow), so this will imply that it will > take > > >> some > > >> > > time > > >> > > > > > > before > > >> > > > > > > > > we do > > >> > > > > > > > > > > a > > >> > > > > > > > > > > > > new > > >> > > > > > > > > > > > > > release. > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > WDTY, > > >> > > > > > > > > > > > > > Robert > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > [1] > > >> https://issues.apache.org/jira/browse/MNG-6656 > > >> > > > > > > > > > > > > > [2] > > >> > > > > > > https://github.com/apache/maven/compare/MNG-6656?expand=1 > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > >> --------------------------------------------------------------------- > > >> > > > > > > > > > > > > > To unsubscribe, e-mail: > > >> > > > dev-unsubscr...@maven.apache.org > > >> > > > > > > > > > > > > > For additional commands, e-mail: > > >> > > > > dev-h...@maven.apache.org > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > -- > > >> > > > > > > > > > > > > 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 > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > -- > > >> > > > > > > > > > > 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 > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > >> --------------------------------------------------------------------- > > >> > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@maven.apache.org > > >> > > > > > > > > For additional commands, e-mail: > > >> dev-h...@maven.apache.org > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > -- > > >> > > > > > > Olivier Lamy > > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
