Hello, Jbit seems quite promising. Really nice work from gnodet as always. -1 for this one. Even though java has new features, most features are basically in terms of expressions enhancements which enables most expressive coding. ( there are various jsr s but this is how i personally and simply see) Other than that, java 8 is still quite common i production envs. Unless you do all fancy cloud stuff and even you do there are so many tech stacks, yet camel as integration framework with or without fancy cloud things is quite powerful and it's been quite fun using it in many usecases rather than focusing only on cloud techies. I appreciate most community people as users are using commercial versions of camel and yet quite many of community are folks of such companies. They do great products with lots of vision and investment and what not so i can understand they want to drive these kinds of decisions in benefit of both products and open source community. Eventually cloud era and keeping up versions as much compatible as with base language features sounds reasonable in many aspects but personally as i have also seen many projects using camel without many of fancy cloud tools and whatnot and also many of them using tools, frameworks and commercial tools. So supporting multiple versions as baseline java 8 sounds better option to me, even though there is maintenance pitfall. Please also note that community members from driving companies of camel OSS have got my full respect so eventually this will be community decision.
Regards On Wed, 1 Jul 2020, 18:05 Guillaume Nodet, <gno...@apache.org> wrote: > Fwiw, I've been investigating translating jdk 14 bytecode into jdk 8 > compatible bytecode. > There are various changes in the JDK: > * new methods: the tool can point to different implementations for the > newly added methods > * var keyword / switch expressions : this require no change in the > bytecode at all as the bytecode generated by those new constructs can be > run on java 8 > * string concatenation: the generated bytecode is completely different > but the tool can handle it > * nested types: haven't tried yet > > So basically, we can easily turn a jdk 11 or jdk 14 jar with a few > limitations into a jdk 8 compatible bytecode. This could be done at > runtime using a java agent or an enhanced classloader, or at build time > using a maven plugin. > The POC is available at > https://github.com/gnodet/jbit > > Which translate the jar containing the following JDK 14 class > > https://github.com/gnodet/jbit/blob/master/example/src/main/java/org/apache/camel/jbit/example/Example.java > into a jar that can be run on JDK 8. > > Le mer. 1 juil. 2020 à 09:45, Omar Al-Safi <o...@oalsafi.com> 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 <anco...@gmail.com> > 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 < > > > j...@nanthrax.net> 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 > > > <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 > > > > >>>> > > > > >>> > > > > > > > > > > > > > > > > -- > ------------------------ > Guillaume Nodet >
