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 > > > > > > > > > > > > > > >
