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 <ancosen1...@yahoo.com.INVALID> 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: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > > > > On Tuesday, June 30, 2020, 05:12:31 PM GMT+2, Jean-Baptiste Onofre > <j...@nanthrax.net> 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 <o...@oalsafi.com> 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 <lburgazz...@gmail.com> >> 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 <gno...@apache.org> >>> 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 <ppal...@redhat.com> 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 <ppal...@redhat.com> >>>>> 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 >>>> >>>
