I'd say that we'll have the same discussion for Java 14, hopefully not for keeping Java 8 but maybe for Java 11 so I think what we need to define is the policy, rather than the specific version.
--- Luca Burgazzoli On Tue, Jun 30, 2020 at 4:56 PM Guillaume Nodet <gno...@apache.org> wrote: > Oh, I wasn't even considering it if it can't be done in a single automated > maven run. > I haven't checked with latest maven plugins, but I was more thinking about > the cost of managing multiple versions of the same source file and how IDE > can support those. > See https://www.baeldung.com/maven-multi-release-jars > I think it can be done for specific spots where it makes sense. > > Here's a short list of JDK language enhancements: > JDK 9-10-11: > * <Collection>.of() > * more functions in the stream api > * private interface methods > * http/2 client support > * local-variable type inference in variables and lambda parameters > * new String methods : isBlank(), lines(), repeat(int), unicode aware > strip(), stripLeading() and stripTrailing() > * new File methods: writeString(), readString() and isSameFile() > JDK 12-13-14: > * switch expressions > * teeing in the stream api > * new String methods: indent(), transform(), formatted(), striIndent(), > translateEscapes() > * new Files.mismatch() method > > I'd be more inclined to wait a bit and jump straight to JDK 14 to be able > to leverage the switch expressions. For new methods on String / File, we > could prepare the code by adding helper methods that would simply call the > JDK ones by leveraging multi-release jars if it can prove useful. > > Another thought would be to leverage some tool like jabel ( > https://github.com/bsideup/jabel) to be able to leverage pure syntactic > sugar improvements, but i've tried to get rid of annotation processors the > last months, so not sure that's a good idea. > > Le mar. 30 juin 2020 à 14:20, Andrea Cosentino <anco...@gmail.com> a > écrit : > > > I don't know if it's feasible, we are already demanding a lot of work to > > the release manager and I guess going through the multi release jar > > approach will be much more troublesome. > > > > Il giorno mar 30 giu 2020 alle ore 14:14 Guillaume Nodet < > > gno...@apache.org> > > ha scritto: > > > > > We could try using the multi-release jar feature in order to leverage > new > > > JDK 11 or JDK 14 features without completely dropping JDK 8, but that's > > > definitely more work. I haven't seen many projects using it yet, so > not > > > sure how that's manageable from a development perspective. > > > > > > Le mar. 30 juin 2020 à 13:50, Luca Burgazzoli <lburgazz...@gmail.com> > a > > > écrit : > > > > > > > I think that unless someone "big" in the OSS makes a move, most > > libraries > > > > will stay with Java 8 till they are forced so I guess someone should > be > > > > brave and make the move. > > > > > > > > --- > > > > Luca Burgazzoli > > > > > > > > > > > > On Tue, Jun 30, 2020 at 12:57 PM Peter Palaga <ppal...@redhat.com> > > > wrote: > > > > > > > > > On 30/06/2020 09:29, Jean-Baptiste Onofre wrote: > > > > > > Agree, I think we should be very careful about communication. > > > > > > > > > > > > It’s the same about EOL branch/release. Actually EOL doesn’t > really > > > > > exist at Apache: anyone can fix/change an old branch and cut a > > release > > > on > > > > > it. > > > > > > So, I fully understand the purpose, but I think we should be more > > > > > "flexible" and communicate early enough to our users. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > >> Le 29 juin 2020 à 22:23, Guillaume Nodet <gno...@apache.org> a > > > écrit > > > > : > > > > > >> > > > > > >> 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? > > > > > > > > > > Are there any other benefits of dropping Java 8? > > > > > > > > > > -- P > > > > > > > > > > >>> 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 > > > > > > > > -- > ------------------------ > Guillaume Nodet >
