[CAMEL 3] Java 8 and Java 11 discussion

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[CAMEL 3] Java 8 and Java 11 discussion

Andrea Cosentino-2
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: [hidden email]
Twitter: @oscerd2
Github: oscerd
Reply | Threaded
Open this post in threaded view
|

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

Willem.Jiang
Administrator
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
<[hidden email]> 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: [hidden email]
> Twitter: @oscerd2
> Github: oscerd
Reply | Threaded
Open this post in threaded view
|

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

Zoran Regvart-2
In reply to this post by Andrea Cosentino-2
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
<[hidden email]> 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: [hidden email]
> Twitter: @oscerd2
> Github: oscerd



--
Zoran Regvart
Reply | Threaded
Open this post in threaded view
|

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

Claus Ibsen-2
On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <[hidden email]> 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
> <[hidden email]> 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: [hidden email]
> > Twitter: @oscerd2
> > Github: oscerd
>
>
>
> --
> Zoran Regvart



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

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

lburgazzoli
+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 <[hidden email]> wrote:

>
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <[hidden email]> 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
> > <[hidden email]> 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: [hidden email]
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

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

Jean-Baptiste Onofré
In reply to this post by Claus Ibsen-2
+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 <[hidden email]> 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
>> <[hidden email]> 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: [hidden email]
>>> Twitter: @oscerd2
>>> Github: oscerd
>>
>>
>>
>> --
>> Zoran Regvart
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

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

Alex Dettinger
+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é <[hidden email]>
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 <[hidden email]> 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
> >> <[hidden email]> 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: [hidden email]
> >>> Twitter: @oscerd2
> >>> Github: oscerd
> >>
> >>
> >>
> >> --
> >> Zoran Regvart
> >
> >
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Reply | Threaded
Open this post in threaded view
|

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

Willem.Jiang
Administrator
In reply to this post by Claus Ibsen-2
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 <[hidden email]> wrote:

>
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart <[hidden email]> 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
> > <[hidden email]> 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: [hidden email]
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2