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
