On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <[email protected]> wrote: > > Hi Cameleers, > my 2 cents on this is that we're now in a different situation than we > were 5-10 years before. It's all about individual deployments, > containers, microservices and such. Enterprises are moving away from > monolithic app servers and thick runtimes and the choice of Java > version is up to the individual applications. > > Coupled with the fact that soon enterprise will have to pay for Java 8 > support[1][2] (which they might not do at the moment), they'd be eager > to switch to the next LTS release: 11 or 17. > > So I would keep a 2.x line with Java 8 as a base and backport fixes > there, and moving to Java 11 as base for 3.x. That would also allow us > to future proof our reactive story with the use of > java.util.concurrent.Flow (introduced in Java 9) in public facing > APIs. > > We have a chance to change APIs and break (some) backward > compatibility with a major version, I think with 3.x we're in a good > position to do that. >
+1 Yeah I would like to base Camel 3 on Java 11 as well. And its going to take about 1 year to get Camel 3 developed and released. > zoran > > [1] > https://blogs.oracle.com/java-platform-group/end-of-public-updates-is-a-process%2c-not-an-event > [2] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html > On Fri, Dec 14, 2018 at 3:03 PM Andrea Cosentino > <[email protected]> wrote: > > > > Hello, > > > > In the other thread about moving the master branch to 3.x, we started a > > discussion around the Java supported version for Camel 3. > > > > Lets discuss this argument here. > > > > Thanks. > > > > -- > > Andrea Cosentino > > ---------------------------------- > > Apache Camel PMC Chair > > Apache Karaf Committer > > Apache Servicemix PMC Member > > Email: [email protected] > > Twitter: @oscerd2 > > Github: oscerd > > > > -- > Zoran Regvart -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
