[CAMEL 3] Java 8 and Java 11 discussion

[Andrea Cosentino <an...@yahoo.com.INVALID>]

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: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Willem Jiang <wi...@gmail.com>]

Hi,

I think for the average the enterprise JDK user they may still use JDK
8 for a very long time.
If we start the Camel 3.x to support JDK 11,  it doesn't mean that we
have to drop the backward compatibility of JDK 8.
Spring has good backward compatibility for JDK 6,7,8[1]. It could be
useful if we can still provide the backward compatibility in Camel 3.x
and if we cannot do that we need to drop a line for it (it depends how
may new feature of JDK 11 we use).

It could be great, if we have a clean roadmap of JDK8, JDK11 support time.

[1]https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 14, 2018 at 10:03 PM Andrea Cosentino
<an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Alex Dettinger <al...@gmail.com>]

+1

The timing is good to bind on Java 11 for camel 3.

Regards,
Alex

On Sun, Dec 16, 2018 at 6:11 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> +1
>
> It makes sense to focus on Java 11 for Camel 3.x and keep Java 8
> compatibility for Camel 2.x.
>
> Regards
> JB
>
> On 16/12/2018 16:34, Claus Ibsen wrote:
> > On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <zo...@regvart.com> 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
> >> <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> >>> Twitter: @oscerd2
> >>> Github: oscerd
> >>
> >>
> >>
> >> --
> >> Zoran Regvart
> >
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

+1

It makes sense to focus on Java 11 for Camel 3.x and keep Java 8
compatibility for Camel 2.x.

Regards
JB

On 16/12/2018 16:34, Claus Ibsen wrote:
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <zo...@regvart.com> 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
>> <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>
>>
>>
>> --
>> Zoran Regvart
> 
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Willem Jiang <wi...@gmail.com>]

It's a great news.  +1 build Camel 3 on top of Java 11.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Dec 16, 2018 at 11:34 PM Claus Ibsen <cl...@gmail.com> wrote:
>
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <zo...@regvart.com> 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
> > <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Luca Burgazzoli <lb...@gmail.com>]

+1 for java 11 only.

btw, netty is doing / thinking about a similar "jump" for netty 5

---
Luca Burgazzoli

On Sun, Dec 16, 2018 at 4:34 PM Claus Ibsen <cl...@gmail.com> wrote:
>
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <zo...@regvart.com> 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
> > <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Claus Ibsen <cl...@gmail.com>]

On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <zo...@regvart.com> 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
> <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
>
>
>
> --
> Zoran Regvart



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Zoran Regvart <zo...@regvart.com>]

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
<an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd



-- 
Zoran Regvart