@Tibor: the design comes from a time functional programming was not mainstream and quite cumbersome with java, let's embrace current way of doing and move forward otherwise we can go to attic ;).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 29 oct. 2019 à 09:02, Tibor Digana <tibordig...@apache.org> a écrit : > 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! > > 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 > > > > > >
