Yeah that is great! +1 Thanks JB!
On Wed, Jul 1, 2020 at 9:46 AM Jean-Baptiste Onofre <[email protected]> wrote: > Agree. I would start a formal vote to propose dropping Java8 in Jan 2021, > it would be clear for everyone. > > Regards > JB > > > Le 1 juil. 2020 à 09:44, Omar Al-Safi <[email protected]> a écrit : > > > > True, Quarkus is more of a concern and from the discussion so far in the > > Quarkus mailing list, change could happen for them as well, therefore we > > can delay dropping Java 8 only for a specific time frame to allow some > > buffer. > > But we have to agree now that we want to *drop* Java 8 and move to either > > Java 11 or 14 let's say at the beginning of 2021 (subject to change on > what > > we agree on), in order to avoid similar discussion later when time comes. > > > > Regards, > > Omar > > > > On Wed, Jul 1, 2020 at 7:58 AM Andrea Cosentino <[email protected]> > wrote: > > > >> Personally I see only Quarkus decision as a concern, we can review the > >> timeline for dropping the Java 8 support. > >> > >> I do believe that is almost impossible to have a codebase working on > Java > >> 8, 11 and 14 and the more time we wait to drop java 8 much more it will > be > >> the work needed to support Java 14 and later. > >> > >> Il giorno mar 30 giu 2020 alle ore 21:03 Jean-Baptiste Onofre < > >> [email protected]> ha scritto: > >> > >>> My point is more about the "form". I’m not against, but it seems we > have > >>> concerns from several people now. So, even if it has been discussed, > >> maybe > >>> we didn’t do a vote or having formal vote. > >>> > >>> Anyway, if you think it’s good enough from a community perspective, I’m > >>> fine with that, and again agree to move forward dropping Java8, but > it’s > >>> weird we have concerns only now (and not during the discussion) ;) > >>> > >>> Regards > >>> JB > >>> > >>>> Le 30 juin 2020 à 18:46, Andrea Cosentino > >> <[email protected]> > >>> a écrit : > >>>> > >>>> It has been already discussed and it's been reported in blog post and > >>> everywhere. It has been said early enough for sure. > >>>> > >>>> -- > >>>> Andrea Cosentino > >>>> ---------------------------------- > >>>> Apache Camel PMC Chair > >>>> Apache Karaf Committer > >>>> Apache Servicemix PMC Member > >>>> Email: [email protected] > >>>> Twitter: @oscerd2 > >>>> Github: oscerd > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Tuesday, June 30, 2020, 05:12:31 PM GMT+2, Jean-Baptiste Onofre < > >>> [email protected]> wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> I think we are all agree about that. But it should be discussed and > >>> announce early enough. > >>>> > >>>> Today, I don’t think we really leverage JDK 9+ stuff. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 30 juin 2020 à 13:49, Omar Al-Safi <[email protected]> a écrit : > >>>>> > >>>>> My question would be, until when we will need to keep Java 8? I mean > >>> sure, > >>>>> given the current circumstances, it might make sense to delay > dropping > >>> Java > >>>>> 8 only for some time, but honestly would be nice if we can embrace > the > >>> new > >>>>> change and massive efforts that are being brought into Java to have > >>>>> modernized (especially the new features being Java 14). It would be a > >>> pity > >>>>> if we can't enjoy these new features being brought in by the Java > >>> community > >>>>> and I don't want to see us stucking with Java 8 for another 10 years. > >>>>> The change has to be forced at some point of the chain in order to > >>> trickle > >>>>> down. > >>>>> > >>>>> These are only my thoughts on this subject. > >>>>> > >>>>> Regards, > >>>>> Omar > >>>>> > >>>>> On Tue, Jun 30, 2020 at 1:33 PM Luca Burgazzoli < > >> [email protected]> > >>>>> wrote: > >>>>> > >>>>>> I don't think that migrating to a new version also means that we > need > >>> to > >>>>>> embrace every new feature automatically but that we can use them > when > >>> it > >>>>>> makes sense but staying with an older version means that we can't > use > >>> them > >>>>>> in any case. > >>>>>> > >>>>>> --- > >>>>>> Luca Burgazzoli > >>>>>> > >>>>>> > >>>>>> On Mon, Jun 29, 2020 at 10:23 PM Guillaume Nodet <[email protected] > > > >>>>>> wrote: > >>>>>> > >>>>>>> Note that we changed a bunch of lambda expressions back to > anonymous > >>>>>>> classes a few months ago, so trying to get to the latest is not > >> always > >>>>>> the > >>>>>>> best choice. > >>>>>>> I'm not sure we need to drop Java 8 now. We can defer that > decision > >>>>>> until > >>>>>>> we have more incentive I think., > >>>>>>> > >>>>>>> Le lun. 29 juin 2020 à 18:01, Peter Palaga <[email protected]> a > >>> écrit > >>>>>> : > >>>>>>> > >>>>>>>> On 29/06/2020 11:59, Peter Palaga wrote: > >>>>>>>>> On 29/06/2020 07:29, Claus Ibsen wrote: > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> On Sun, Jun 28, 2020 at 4:28 PM Peter Palaga < > [email protected] > >>> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Claus, > >>>>>>>>>>> > >>>>>>>>>>> we have announced a similar move for Camel Quarkus some time > >> ago. > >>>>>> We > >>>>>>>> did > >>>>>>>>>>> that based on a similar Quarkus announcement [1]. But when I > was > >>>>>>> about > >>>>>>>>>>> to perform the necessary changes, it turned out that Quarkus > got > >>>>>> some > >>>>>>>>>>> pushback from the users and thus they abandoned the plan > without > >>>>>>>> letting > >>>>>>>>>>> us know - see [2]. As a result, Camel Quarkus also had to > >> revisit > >>>>>> the > >>>>>>>>>>> plan. We have decided to make Java 11 our main build and > testing > >>>>>> JDK, > >>>>>>>>>>> but kept both source and target compatibility at Java 8. > >>>>>>>>>>> > >>>>>>>>>>> Requiring Java 11+ API on the Camel side would put Camel > Quarkus > >>>>>> in a > >>>>>>>>>>> bit uncomfortable position: unlike all other extensions offered > >>> via > >>>>>>>>>>> code.quarkus.io, our extensions would not work on Java 8 in > JVM > >>>>>>> mode. > >>>>>>>>>>> > >>>>>>>>>>> We (Camel community) should figure out how to proceed. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> The drop of Java 8 is planned for next LTS (Camel 3.7) which is > >> by > >>>>>> end > >>>>>>>>>> of this year. > >>>>>>>>>> So there is still 6 months to go. In that time Quarkus may get > >> to a > >>>>>>>>>> point where they have dropped Java 8 as well. > >>>>>>>>>> > >>>>>>>>>> But for Camel 3.5 we can surely wait to drop Java 8 so it does > >> not > >>>>>>>>>> happen soon on the Camel side. > >>>>>>>>>> > >>>>>>>>>> Would ou you go ask the Quarkus team what new timeframe they > have > >>>>>> for > >>>>>>>>>> dropping Java 8? > >>>>>>>>> > >>>>>>>>> Asked > >>>>>> https://groups.google.com/forum/#!topic/quarkus-dev/7SZAM2BMb9c > >>>>>>>> > >>>>>>>> They asked back, what are our motivations for removing Java 8. I > >> can > >>>>>> say > >>>>>>>> for myself that it is mainly a simplification of our testing > >> matrix. > >>>>>> Are > >>>>>>>> there any other reasons? > >>>>>>>> > >>>>>>>> Besides they noted that Azure Functions still only supports Java > 8. > >>>>>>>> > >>>>>>>> -- P > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> [1] > >>>>>>>>>>> > >>>>>>> > >> https://quarkus.io/blog/quarkus-1-4-final-released/#java-8-deprecated > >>>>>>>>>>> [2] > >>>>>>>> > >> https://groups.google.com/d/msg/quarkus-dev/yzEjmYCFbwY/oW64kts3AQAJ > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> -- Peter > >>>>>>>>>>> > >>>>>>>>>>> On 26/06/2020 10:23, Claus Ibsen wrote: > >>>>>>>>>>>> Hi > >>>>>>>>>>>> > >>>>>>>>>>>> Just a heads up that from Camel 3.5 onwards we will drop Java > 8 > >>>>>>>>>>>> support. > >>>>>>>>>>>> > >>>>>>>>>>>> So this means that minimum Java version is now Java 11. > >>>>>>>>>>>> We are also working on adding support for Java 14, but it may > >>>>>> take a > >>>>>>>>>>>> few releases, but its planned for the next LTS 3.7 release to > >>> have > >>>>>>>>>>>> both Java 11 and 14 as supported. > >>>>>>>>>>>> > >>>>>>>>>>>> Camel 3.4.x is the LTS release that supports both Java 8 and > >> 11, > >>>>>> and > >>>>>>>>>>>> its supported for 1-year (june 2022). > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> ------------------------ > >>>>>>> Guillaume Nodet > >>>>>>> > >>>>>> > >>> > >>> > >> > >
