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. 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
