You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Lari Hotari <lh...@apache.org> on 2022/05/09 10:03:13 UTC
Re: [VOTE] PIP-156: Build and Run Pulsar Server on Java 17
PIP-156 PR https://github.com/apache/pulsar/pull/15264 has been merged to master branch.
Please notice that Java 17 is now required for building Pulsar master branch.
btw. https://sdkman.io/ is handy for managing multiple JDK versions in local development environments.
-Lari
On 2022/04/20 16:37:21 Heesung Sohn wrote:
> Dear Pulsar Community,
>
> Please review and vote on this PIP.
>
> PIP link : https://github.com/apache/pulsar/issues/15207
>
> Thank you,
> --
>
> <https://streamnative.io>
>
> Heesung Sohn
>
> Platform Engineer
>
> e: heesung.sohn@streamnative.io
>
> streamnative.io
>
> <http://github.com/streamnative>
> <https://www.linkedin.com/company/streamnative/>
> <https://twitter.com/streamnativeio/>
>
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Nicolò Boschi <bo...@gmail.com>.
Hi all,
I believe we're encountering the issue related to cherry-picking to the
release branches.
Since the master is on JDK17 now it is allowed to use language features
from jdk9 onwards.
This is a horrible problem for those pulls that need to be cherry-picked to
release branches.
Now we are in a situation where Pulsar 2.10 is at early stages and we're
setting it to LTS for our users.
Currently we cherry-pick a LOT of commits to branch 2.10 (e.g. in the
latest week we ported 43 commits).
We need to figure out how to deal with this. I'll share some ideas
1) Do not use new language features until 2.10 is EOL (very long time)
2) Do allow new language features usages only for new features that we are
very sure won't be cherry-picked.
This is an example of a pull that needs to be converted:
https://github.com/apache/pulsar/pull/15779.
I disagree with this kind of "conversion" because not all the language
features have an exact replacement and also the code could diverge too much
and lead to conditions where other commits (maybe very important fixes) may
be hardly portable.
I know the main goal of this whole work is to be able to use new language
features but I believe maintaining release branches is more important for
the Pulsar community.
What do you think?
Nicolò Boschi
Il giorno lun 16 mag 2022 alle ore 03:53 Jia Zhai <zh...@apache.org> ha
scritto:
> Hi Dezhi, and Teng,
> FYI. Here is the thread that discusses JDK 17.
>
> On Thu, May 12, 2022 at 8:22 AM Matteo Merli <ma...@gmail.com>
> wrote:
>
> > --
> > Matteo Merli
> > <ma...@gmail.com>
> >
> > On Wed, May 11, 2022 at 11:10 AM Dave Fisher <wa...@apache.org> wrote:
> > >
> > >
> > >
> > > > On May 11, 2022, at 6:39 AM, Matteo Merli <ma...@gmail.com>
> > wrote:
> > > >
> > > > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eolivelli@gmail.com
> >
> > wrote:
> > > >> I am sorry, I missed this discussion.
> > > >> But until we cut a release we are in time to change our minds, if we
> > > >> find out that we can do better.
> > > >
> > > > Yes, but the precise point of having a PIP process is to have
> > > > discussions and formalize decisions.
> > >
> > > One of my criticisms of the current PIP process is that there is a 2
> day
> > VOTE period. This is just too short for ASF project governance. Not
> > everyone is online or checking the dev list in detail in that short a
> > period. There are weekends, holidays, work focus (even if Pulsar is your
> > job). Many PIPs are minor, but some are of very large impact and should
> > perhaps have a 7 day VOTE and/or 7 days minimum discussion time.
> >
> > Sure, this is a very valid point. The initial reasoning for the 2 days
> > was not to disrupt too much the introduction of smaller changes, since
> > we went from no-process at all to this discussion/vote PIP process.
> >
> > We can (should!) definitely revisit the process, now that we have some
> > experience with it.
> > Typically, what would be challenging is to define what is "large
> > impact" (even if this proposal certainly will fit the bill) as
> > everyone could have different perspectives on it, but at least we can
> > set the expectations to be different for different types of changes.
> >
> > The current PIP-156 stayed out for discussion/vote for 1 week (which I
> > agree is not a whole lot of time), although it has been discussed
> > informally in the community a few times before.
> >
> > What I'd also like to avoid is for us to go back on the same decisions
> > once they're taken, unless there are new elements that were not
> > considered before.
> >
> > > 1. We should likely declare that 2.10 releases are LTS to allow
> > stability for users that must remain on Java 8.
> >
> > This sounds like a good point.
> >
> >
> > > 2. We’ll need to provide clear guidance to developers on code changes
> > that will be cherry picked to 2.10 and earlier versions.
> >
> > Sure, this is easy. We need to update the contributor/committer
> > guidelines and the CI jobs will ensure that we don't slip anything
> > inadvertently.
> >
>
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Jia Zhai <zh...@apache.org>.
Hi Dezhi, and Teng,
FYI. Here is the thread that discusses JDK 17.
On Thu, May 12, 2022 at 8:22 AM Matteo Merli <ma...@gmail.com> wrote:
> --
> Matteo Merli
> <ma...@gmail.com>
>
> On Wed, May 11, 2022 at 11:10 AM Dave Fisher <wa...@apache.org> wrote:
> >
> >
> >
> > > On May 11, 2022, at 6:39 AM, Matteo Merli <ma...@gmail.com>
> wrote:
> > >
> > > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
> > >> I am sorry, I missed this discussion.
> > >> But until we cut a release we are in time to change our minds, if we
> > >> find out that we can do better.
> > >
> > > Yes, but the precise point of having a PIP process is to have
> > > discussions and formalize decisions.
> >
> > One of my criticisms of the current PIP process is that there is a 2 day
> VOTE period. This is just too short for ASF project governance. Not
> everyone is online or checking the dev list in detail in that short a
> period. There are weekends, holidays, work focus (even if Pulsar is your
> job). Many PIPs are minor, but some are of very large impact and should
> perhaps have a 7 day VOTE and/or 7 days minimum discussion time.
>
> Sure, this is a very valid point. The initial reasoning for the 2 days
> was not to disrupt too much the introduction of smaller changes, since
> we went from no-process at all to this discussion/vote PIP process.
>
> We can (should!) definitely revisit the process, now that we have some
> experience with it.
> Typically, what would be challenging is to define what is "large
> impact" (even if this proposal certainly will fit the bill) as
> everyone could have different perspectives on it, but at least we can
> set the expectations to be different for different types of changes.
>
> The current PIP-156 stayed out for discussion/vote for 1 week (which I
> agree is not a whole lot of time), although it has been discussed
> informally in the community a few times before.
>
> What I'd also like to avoid is for us to go back on the same decisions
> once they're taken, unless there are new elements that were not
> considered before.
>
> > 1. We should likely declare that 2.10 releases are LTS to allow
> stability for users that must remain on Java 8.
>
> This sounds like a good point.
>
>
> > 2. We’ll need to provide clear guidance to developers on code changes
> that will be cherry picked to 2.10 and earlier versions.
>
> Sure, this is easy. We need to update the contributor/committer
> guidelines and the CI jobs will ensure that we don't slip anything
> inadvertently.
>
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Matteo Merli <ma...@gmail.com>.
--
Matteo Merli
<ma...@gmail.com>
On Wed, May 11, 2022 at 11:10 AM Dave Fisher <wa...@apache.org> wrote:
>
>
>
> > On May 11, 2022, at 6:39 AM, Matteo Merli <ma...@gmail.com> wrote:
> >
> > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com> wrote:
> >> I am sorry, I missed this discussion.
> >> But until we cut a release we are in time to change our minds, if we
> >> find out that we can do better.
> >
> > Yes, but the precise point of having a PIP process is to have
> > discussions and formalize decisions.
>
> One of my criticisms of the current PIP process is that there is a 2 day VOTE period. This is just too short for ASF project governance. Not everyone is online or checking the dev list in detail in that short a period. There are weekends, holidays, work focus (even if Pulsar is your job). Many PIPs are minor, but some are of very large impact and should perhaps have a 7 day VOTE and/or 7 days minimum discussion time.
Sure, this is a very valid point. The initial reasoning for the 2 days
was not to disrupt too much the introduction of smaller changes, since
we went from no-process at all to this discussion/vote PIP process.
We can (should!) definitely revisit the process, now that we have some
experience with it.
Typically, what would be challenging is to define what is "large
impact" (even if this proposal certainly will fit the bill) as
everyone could have different perspectives on it, but at least we can
set the expectations to be different for different types of changes.
The current PIP-156 stayed out for discussion/vote for 1 week (which I
agree is not a whole lot of time), although it has been discussed
informally in the community a few times before.
What I'd also like to avoid is for us to go back on the same decisions
once they're taken, unless there are new elements that were not
considered before.
> 1. We should likely declare that 2.10 releases are LTS to allow stability for users that must remain on Java 8.
This sounds like a good point.
> 2. We’ll need to provide clear guidance to developers on code changes that will be cherry picked to 2.10 and earlier versions.
Sure, this is easy. We need to update the contributor/committer
guidelines and the CI jobs will ensure that we don't slip anything
inadvertently.
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Dave Fisher <wa...@apache.org>.
> On May 11, 2022, at 6:39 AM, Matteo Merli <ma...@gmail.com> wrote:
>
> On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com> wrote:
>> I am sorry, I missed this discussion.
>> But until we cut a release we are in time to change our minds, if we
>> find out that we can do better.
>
> Yes, but the precise point of having a PIP process is to have
> discussions and formalize decisions.
One of my criticisms of the current PIP process is that there is a 2 day VOTE period. This is just too short for ASF project governance. Not everyone is online or checking the dev list in detail in that short a period. There are weekends, holidays, work focus (even if Pulsar is your job). Many PIPs are minor, but some are of very large impact and should perhaps have a 7 day VOTE and/or 7 days minimum discussion time.
This particular PIP has a large impact and I think that even if it proceeds there are certain additional discussions and decisions that are required.
1. We should likely declare that 2.10 releases are LTS to allow stability for users that must remain on Java 8.
2. We’ll need to provide clear guidance to developers on code changes that will be cherry picked to 2.10 and earlier versions.
ATB,
Dave
>
>>
>>>
>>> It is not that the PR came out of the blue. Obviously every decision
>>> can be re-visited if there are additional details, though it would be
>>> better if we get the feedback at the time the proposal.
>>>
>>> To reiterate the rationale for going directly to 17:
>>>
>>> 1. Requiring Java 11 won't buy us anything new and will at the same
>>> time require changes from the part of the users.
>>> 2. 17 is a Java LTS release that will be out for 1 year from the
>>> moment in which we release Pulsar 2.11
>>> 3. It is a stable release with widely available packages for every
>>> platform and from every Java vendor.
>>> 4. We are setting up for 4 years of active support of Java 17,
>>> compared to just 1 year of Java 11
>>> 5. There are several source-level features introduced in 12+ that we
>>> can take advantage of in our codebase
>>
>> I understand your points, and I would be really excited to start using
>> Records and other features (and Valhalla, Loop and Panama as soon as
>> they are available)
>>
>> But on the other side now in the Pulsar ecosystem we have big
>> enterprises that are not keen on changing JDK so quickly.
>>
>> Up to version 2.10 Pulsar still worked well on JDK8.
>>
>> We cannot require users to switch from JDK8 to JDK17 while upgrading Pulsar.
>
> Why not? We can ask to upgrade to Java 11 but not 17?
>
>>
>> We have been running, building and testing Pulsar on JDK11 for many
>> major releases (from 2.7 onwards) (and the docker images in 2.10 are
>> with JDK11)
>> so it is time to require JDK11.
>
> Requiring Java 11 would be pointless as there are very few Java source
> level features we can take advantage of.
>
>>
>> I believe that the best plan, in the interest of our community and of
>> the enterprises who choose to switch to Pulsar,
>> is to still allow all Pulsar components to run on JDK11 (and the
>> client on JDK8) for 2.11.
>>
>> We can switch to requiring JDK17 in 2.12.
>
> I do not agree with this assessment and I think the best plan is to
> continue with the current decision of switching to Java 17.
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Matteo Merli <ma...@gmail.com>.
The proposal is to keep java 8 for client library and only move server side
to 17 :)
On Wed, May 11, 2022 at 11:05 AM Rajan Dhabalia <rd...@apache.org>
wrote:
> Hi,
>
> I do not agree to force client applications to use jdk-17 and that will not
> be good Pulsar as a project because that will force users to find another
> alternative of Pulsar for their messaging usecases. In large org where
> Pulsar is being used as a managed service and used by a large number of
> applications can upgrade Pulsar for their critical bug fixes but they can
> not move to jdk-17 that easily. Forcing and asking users to switch to jdk17
> will be a disaster in the short term because messaging could be a small use
> case component in their large application and it's not easy for them to
> switch to jdk17 immediately to use the latest pulsar library. So, I
> strongly discourage the Pulsar community to strictly move to jdk17 and
> provide jdk-11 support for sometime.
>
> Thanks,
> Rajan
>
> On Wed, May 11, 2022 at 6:40 AM Matteo Merli <ma...@gmail.com>
> wrote:
>
> > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> > > I am sorry, I missed this discussion.
> > > But until we cut a release we are in time to change our minds, if we
> > > find out that we can do better.
> >
> > Yes, but the precise point of having a PIP process is to have
> > discussions and formalize decisions.
> >
> > >
> > > >
> > > > It is not that the PR came out of the blue. Obviously every decision
> > > > can be re-visited if there are additional details, though it would be
> > > > better if we get the feedback at the time the proposal.
> > > >
> > > > To reiterate the rationale for going directly to 17:
> > > >
> > > > 1. Requiring Java 11 won't buy us anything new and will at the same
> > > > time require changes from the part of the users.
> > > > 2. 17 is a Java LTS release that will be out for 1 year from the
> > > > moment in which we release Pulsar 2.11
> > > > 3. It is a stable release with widely available packages for every
> > > > platform and from every Java vendor.
> > > > 4. We are setting up for 4 years of active support of Java 17,
> > > > compared to just 1 year of Java 11
> > > > 5. There are several source-level features introduced in 12+ that we
> > > > can take advantage of in our codebase
> > >
> > > I understand your points, and I would be really excited to start using
> > > Records and other features (and Valhalla, Loop and Panama as soon as
> > > they are available)
> > >
> > > But on the other side now in the Pulsar ecosystem we have big
> > > enterprises that are not keen on changing JDK so quickly.
> > >
> > > Up to version 2.10 Pulsar still worked well on JDK8.
> > >
> > > We cannot require users to switch from JDK8 to JDK17 while upgrading
> > Pulsar.
> >
> > Why not? We can ask to upgrade to Java 11 but not 17?
> >
> > >
> > > We have been running, building and testing Pulsar on JDK11 for many
> > > major releases (from 2.7 onwards) (and the docker images in 2.10 are
> > > with JDK11)
> > > so it is time to require JDK11.
> >
> > Requiring Java 11 would be pointless as there are very few Java source
> > level features we can take advantage of.
> >
> > >
> > > I believe that the best plan, in the interest of our community and of
> > > the enterprises who choose to switch to Pulsar,
> > > is to still allow all Pulsar components to run on JDK11 (and the
> > > client on JDK8) for 2.11.
> > >
> > > We can switch to requiring JDK17 in 2.12.
> >
> > I do not agree with this assessment and I think the best plan is to
> > continue with the current decision of switching to Java 17.
> >
>
--
--
Matteo Merli
<ma...@gmail.com>
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Rajan Dhabalia <rd...@apache.org>.
Hi,
I do not agree to force client applications to use jdk-17 and that will not
be good Pulsar as a project because that will force users to find another
alternative of Pulsar for their messaging usecases. In large org where
Pulsar is being used as a managed service and used by a large number of
applications can upgrade Pulsar for their critical bug fixes but they can
not move to jdk-17 that easily. Forcing and asking users to switch to jdk17
will be a disaster in the short term because messaging could be a small use
case component in their large application and it's not easy for them to
switch to jdk17 immediately to use the latest pulsar library. So, I
strongly discourage the Pulsar community to strictly move to jdk17 and
provide jdk-11 support for sometime.
Thanks,
Rajan
On Wed, May 11, 2022 at 6:40 AM Matteo Merli <ma...@gmail.com> wrote:
> On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
> > I am sorry, I missed this discussion.
> > But until we cut a release we are in time to change our minds, if we
> > find out that we can do better.
>
> Yes, but the precise point of having a PIP process is to have
> discussions and formalize decisions.
>
> >
> > >
> > > It is not that the PR came out of the blue. Obviously every decision
> > > can be re-visited if there are additional details, though it would be
> > > better if we get the feedback at the time the proposal.
> > >
> > > To reiterate the rationale for going directly to 17:
> > >
> > > 1. Requiring Java 11 won't buy us anything new and will at the same
> > > time require changes from the part of the users.
> > > 2. 17 is a Java LTS release that will be out for 1 year from the
> > > moment in which we release Pulsar 2.11
> > > 3. It is a stable release with widely available packages for every
> > > platform and from every Java vendor.
> > > 4. We are setting up for 4 years of active support of Java 17,
> > > compared to just 1 year of Java 11
> > > 5. There are several source-level features introduced in 12+ that we
> > > can take advantage of in our codebase
> >
> > I understand your points, and I would be really excited to start using
> > Records and other features (and Valhalla, Loop and Panama as soon as
> > they are available)
> >
> > But on the other side now in the Pulsar ecosystem we have big
> > enterprises that are not keen on changing JDK so quickly.
> >
> > Up to version 2.10 Pulsar still worked well on JDK8.
> >
> > We cannot require users to switch from JDK8 to JDK17 while upgrading
> Pulsar.
>
> Why not? We can ask to upgrade to Java 11 but not 17?
>
> >
> > We have been running, building and testing Pulsar on JDK11 for many
> > major releases (from 2.7 onwards) (and the docker images in 2.10 are
> > with JDK11)
> > so it is time to require JDK11.
>
> Requiring Java 11 would be pointless as there are very few Java source
> level features we can take advantage of.
>
> >
> > I believe that the best plan, in the interest of our community and of
> > the enterprises who choose to switch to Pulsar,
> > is to still allow all Pulsar components to run on JDK11 (and the
> > client on JDK8) for 2.11.
> >
> > We can switch to requiring JDK17 in 2.12.
>
> I do not agree with this assessment and I think the best plan is to
> continue with the current decision of switching to Java 17.
>
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Matteo Merli <ma...@gmail.com>.
On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eo...@gmail.com> wrote:
> I am sorry, I missed this discussion.
> But until we cut a release we are in time to change our minds, if we
> find out that we can do better.
Yes, but the precise point of having a PIP process is to have
discussions and formalize decisions.
>
> >
> > It is not that the PR came out of the blue. Obviously every decision
> > can be re-visited if there are additional details, though it would be
> > better if we get the feedback at the time the proposal.
> >
> > To reiterate the rationale for going directly to 17:
> >
> > 1. Requiring Java 11 won't buy us anything new and will at the same
> > time require changes from the part of the users.
> > 2. 17 is a Java LTS release that will be out for 1 year from the
> > moment in which we release Pulsar 2.11
> > 3. It is a stable release with widely available packages for every
> > platform and from every Java vendor.
> > 4. We are setting up for 4 years of active support of Java 17,
> > compared to just 1 year of Java 11
> > 5. There are several source-level features introduced in 12+ that we
> > can take advantage of in our codebase
>
> I understand your points, and I would be really excited to start using
> Records and other features (and Valhalla, Loop and Panama as soon as
> they are available)
>
> But on the other side now in the Pulsar ecosystem we have big
> enterprises that are not keen on changing JDK so quickly.
>
> Up to version 2.10 Pulsar still worked well on JDK8.
>
> We cannot require users to switch from JDK8 to JDK17 while upgrading Pulsar.
Why not? We can ask to upgrade to Java 11 but not 17?
>
> We have been running, building and testing Pulsar on JDK11 for many
> major releases (from 2.7 onwards) (and the docker images in 2.10 are
> with JDK11)
> so it is time to require JDK11.
Requiring Java 11 would be pointless as there are very few Java source
level features we can take advantage of.
>
> I believe that the best plan, in the interest of our community and of
> the enterprises who choose to switch to Pulsar,
> is to still allow all Pulsar components to run on JDK11 (and the
> client on JDK8) for 2.11.
>
> We can switch to requiring JDK17 in 2.12.
I do not agree with this assessment and I think the best plan is to
continue with the current decision of switching to Java 17.
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Enrico Olivelli <eo...@gmail.com>.
Matteo,
Il giorno lun 9 mag 2022 alle ore 19:34 Matteo Merli
<ma...@gmail.com> ha scritto:
>
> We have already had several discussions on this subject, on the
> by-weekly community call, on the PIP proposal and finally the PIP
> vote.
I am sorry, I missed this discussion.
But until we cut a release we are in time to change our minds, if we
find out that we can do better.
>
> It is not that the PR came out of the blue. Obviously every decision
> can be re-visited if there are additional details, though it would be
> better if we get the feedback at the time the proposal.
>
> To reiterate the rationale for going directly to 17:
>
> 1. Requiring Java 11 won't buy us anything new and will at the same
> time require changes from the part of the users.
> 2. 17 is a Java LTS release that will be out for 1 year from the
> moment in which we release Pulsar 2.11
> 3. It is a stable release with widely available packages for every
> platform and from every Java vendor.
> 4. We are setting up for 4 years of active support of Java 17,
> compared to just 1 year of Java 11
> 5. There are several source-level features introduced in 12+ that we
> can take advantage of in our codebase
I understand your points, and I would be really excited to start using
Records and other features (and Valhalla, Loop and Panama as soon as
they are available)
But on the other side now in the Pulsar ecosystem we have big
enterprises that are not keen on changing JDK so quickly.
Up to version 2.10 Pulsar still worked well on JDK8.
We cannot require users to switch from JDK8 to JDK17 while upgrading Pulsar.
We have been running, building and testing Pulsar on JDK11 for many
major releases (from 2.7 onwards) (and the docker images in 2.10 are
with JDK11)
so it is time to require JDK11.
I believe that the best plan, in the interest of our community and of
the enterprises who choose to switch to Pulsar,
is to still allow all Pulsar components to run on JDK11 (and the
client on JDK8) for 2.11.
We can switch to requiring JDK17 in 2.12.
This is my PR
https://github.com/apache/pulsar/pull/15512
Enrico
>
>
> --
> Matteo Merli
> <ma...@gmail.com>
>
> On Mon, May 9, 2022 at 9:33 AM Neng Lu <nl...@apache.org> wrote:
> >
> > +1 for requiring JDK11 and prepare for JDK17
> >
> > On 2022/05/09 11:03:27 Enrico Olivelli wrote:
> > > I am sorry,
> > > I have missed this thread.
> > >
> > > I believe that requiring JDK17 to build and especially to RUN the
> > > Pulsar broker is not a good idea currently.
> > > Many enterprises, especially the bigger, or banks, insurance
> > > companies....have strict requirements on some components and they are
> > > very slow to accept bleeding edge tecnologie.
> > >
> > > I believe that it is good to run CI on JDK17 and also to build the
> > > docker images on JDK17.
> > > But I know a few companies who won't be able to switch to JDK17 very quickly.
> > >
> > > I think it is better to require JDK11 at this moment, and not JDK17,
> > > otherwise users will be stuck with Pulsar 2.10 for a long time.
> > >
> > > Requiring JDK17 would be justified only if there is some required new
> > > feature, but this is not the case.
> > >
> > > So I propose to change the required JDK version to build and run to
> > > JDK11 for the server part and JDK8 for the client.
> > >
> > > Enrico
> > >
> > > Il giorno lun 9 mag 2022 alle ore 12:03 Lari Hotari
> > > <lh...@apache.org> ha scritto:
> > > >
> > > > PIP-156 PR https://github.com/apache/pulsar/pull/15264 has been merged to master branch.
> > > >
> > > > Please notice that Java 17 is now required for building Pulsar master branch.
> > > >
> > > > btw. https://sdkman.io/ is handy for managing multiple JDK versions in local development environments.
> > > >
> > > > -Lari
> > > >
> > > >
> > > > On 2022/04/20 16:37:21 Heesung Sohn wrote:
> > > > > Dear Pulsar Community,
> > > > >
> > > > > Please review and vote on this PIP.
> > > > >
> > > > > PIP link : https://github.com/apache/pulsar/issues/15207
> > > > >
> > > > > Thank you,
> > > > > --
> > > > >
> > > > > <https://streamnative.io>
> > > > >
> > > > > Heesung Sohn
> > > > >
> > > > > Platform Engineer
> > > > >
> > > > > e: heesung.sohn@streamnative.io
> > > > >
> > > > > streamnative.io
> > > > >
> > > > > <http://github.com/streamnative>
> > > > > <https://www.linkedin.com/company/streamnative/>
> > > > > <https://twitter.com/streamnativeio/>
> > > > >
> > >
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Matteo Merli <ma...@gmail.com>.
We have already had several discussions on this subject, on the
by-weekly community call, on the PIP proposal and finally the PIP
vote.
It is not that the PR came out of the blue. Obviously every decision
can be re-visited if there are additional details, though it would be
better if we get the feedback at the time the proposal.
To reiterate the rationale for going directly to 17:
1. Requiring Java 11 won't buy us anything new and will at the same
time require changes from the part of the users.
2. 17 is a Java LTS release that will be out for 1 year from the
moment in which we release Pulsar 2.11
3. It is a stable release with widely available packages for every
platform and from every Java vendor.
4. We are setting up for 4 years of active support of Java 17,
compared to just 1 year of Java 11
5. There are several source-level features introduced in 12+ that we
can take advantage of in our codebase
--
Matteo Merli
<ma...@gmail.com>
On Mon, May 9, 2022 at 9:33 AM Neng Lu <nl...@apache.org> wrote:
>
> +1 for requiring JDK11 and prepare for JDK17
>
> On 2022/05/09 11:03:27 Enrico Olivelli wrote:
> > I am sorry,
> > I have missed this thread.
> >
> > I believe that requiring JDK17 to build and especially to RUN the
> > Pulsar broker is not a good idea currently.
> > Many enterprises, especially the bigger, or banks, insurance
> > companies....have strict requirements on some components and they are
> > very slow to accept bleeding edge tecnologie.
> >
> > I believe that it is good to run CI on JDK17 and also to build the
> > docker images on JDK17.
> > But I know a few companies who won't be able to switch to JDK17 very quickly.
> >
> > I think it is better to require JDK11 at this moment, and not JDK17,
> > otherwise users will be stuck with Pulsar 2.10 for a long time.
> >
> > Requiring JDK17 would be justified only if there is some required new
> > feature, but this is not the case.
> >
> > So I propose to change the required JDK version to build and run to
> > JDK11 for the server part and JDK8 for the client.
> >
> > Enrico
> >
> > Il giorno lun 9 mag 2022 alle ore 12:03 Lari Hotari
> > <lh...@apache.org> ha scritto:
> > >
> > > PIP-156 PR https://github.com/apache/pulsar/pull/15264 has been merged to master branch.
> > >
> > > Please notice that Java 17 is now required for building Pulsar master branch.
> > >
> > > btw. https://sdkman.io/ is handy for managing multiple JDK versions in local development environments.
> > >
> > > -Lari
> > >
> > >
> > > On 2022/04/20 16:37:21 Heesung Sohn wrote:
> > > > Dear Pulsar Community,
> > > >
> > > > Please review and vote on this PIP.
> > > >
> > > > PIP link : https://github.com/apache/pulsar/issues/15207
> > > >
> > > > Thank you,
> > > > --
> > > >
> > > > <https://streamnative.io>
> > > >
> > > > Heesung Sohn
> > > >
> > > > Platform Engineer
> > > >
> > > > e: heesung.sohn@streamnative.io
> > > >
> > > > streamnative.io
> > > >
> > > > <http://github.com/streamnative>
> > > > <https://www.linkedin.com/company/streamnative/>
> > > > <https://twitter.com/streamnativeio/>
> > > >
> >
Re: Build Pulsar Server on Java 17- too strict ?
Posted by Neng Lu <nl...@apache.org>.
+1 for requiring JDK11 and prepare for JDK17
On 2022/05/09 11:03:27 Enrico Olivelli wrote:
> I am sorry,
> I have missed this thread.
>
> I believe that requiring JDK17 to build and especially to RUN the
> Pulsar broker is not a good idea currently.
> Many enterprises, especially the bigger, or banks, insurance
> companies....have strict requirements on some components and they are
> very slow to accept bleeding edge tecnologie.
>
> I believe that it is good to run CI on JDK17 and also to build the
> docker images on JDK17.
> But I know a few companies who won't be able to switch to JDK17 very quickly.
>
> I think it is better to require JDK11 at this moment, and not JDK17,
> otherwise users will be stuck with Pulsar 2.10 for a long time.
>
> Requiring JDK17 would be justified only if there is some required new
> feature, but this is not the case.
>
> So I propose to change the required JDK version to build and run to
> JDK11 for the server part and JDK8 for the client.
>
> Enrico
>
> Il giorno lun 9 mag 2022 alle ore 12:03 Lari Hotari
> <lh...@apache.org> ha scritto:
> >
> > PIP-156 PR https://github.com/apache/pulsar/pull/15264 has been merged to master branch.
> >
> > Please notice that Java 17 is now required for building Pulsar master branch.
> >
> > btw. https://sdkman.io/ is handy for managing multiple JDK versions in local development environments.
> >
> > -Lari
> >
> >
> > On 2022/04/20 16:37:21 Heesung Sohn wrote:
> > > Dear Pulsar Community,
> > >
> > > Please review and vote on this PIP.
> > >
> > > PIP link : https://github.com/apache/pulsar/issues/15207
> > >
> > > Thank you,
> > > --
> > >
> > > <https://streamnative.io>
> > >
> > > Heesung Sohn
> > >
> > > Platform Engineer
> > >
> > > e: heesung.sohn@streamnative.io
> > >
> > > streamnative.io
> > >
> > > <http://github.com/streamnative>
> > > <https://www.linkedin.com/company/streamnative/>
> > > <https://twitter.com/streamnativeio/>
> > >
>
Build Pulsar Server on Java 17- too strict ?
Posted by Enrico Olivelli <eo...@gmail.com>.
I am sorry,
I have missed this thread.
I believe that requiring JDK17 to build and especially to RUN the
Pulsar broker is not a good idea currently.
Many enterprises, especially the bigger, or banks, insurance
companies....have strict requirements on some components and they are
very slow to accept bleeding edge tecnologie.
I believe that it is good to run CI on JDK17 and also to build the
docker images on JDK17.
But I know a few companies who won't be able to switch to JDK17 very quickly.
I think it is better to require JDK11 at this moment, and not JDK17,
otherwise users will be stuck with Pulsar 2.10 for a long time.
Requiring JDK17 would be justified only if there is some required new
feature, but this is not the case.
So I propose to change the required JDK version to build and run to
JDK11 for the server part and JDK8 for the client.
Enrico
Il giorno lun 9 mag 2022 alle ore 12:03 Lari Hotari
<lh...@apache.org> ha scritto:
>
> PIP-156 PR https://github.com/apache/pulsar/pull/15264 has been merged to master branch.
>
> Please notice that Java 17 is now required for building Pulsar master branch.
>
> btw. https://sdkman.io/ is handy for managing multiple JDK versions in local development environments.
>
> -Lari
>
>
> On 2022/04/20 16:37:21 Heesung Sohn wrote:
> > Dear Pulsar Community,
> >
> > Please review and vote on this PIP.
> >
> > PIP link : https://github.com/apache/pulsar/issues/15207
> >
> > Thank you,
> > --
> >
> > <https://streamnative.io>
> >
> > Heesung Sohn
> >
> > Platform Engineer
> >
> > e: heesung.sohn@streamnative.io
> >
> > streamnative.io
> >
> > <http://github.com/streamnative>
> > <https://www.linkedin.com/company/streamnative/>
> > <https://twitter.com/streamnativeio/>
> >