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