Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Patrick Hunt]

I'd recommend starting a separate [VOTE] thread to make it more obvious. Is
there a jira? I didn't see it on this thread, would be good to
create/document.

Regards,

Patrick

On Thu, Mar 22, 2018 at 10:43 AM, Andor Molnar  wrote:

> Silence probably means 'yes', so I start the vote now.
>
> *Shall we upgrade the minimum required Java version to compile and run
> ZooKeeper on 3.5 and master branches to Java 1.8?*
>
> *Yes / No*
>
> I vote for 'Yes'.
>
> Regards,
> Andor
>
>
>
> On Mon, Mar 19, 2018 at 1:35 PM, Andor Molnar  wrote:
>
> > From the responses on 'user' list, I think we are good to go.
> >
> > What do you think?
> >
> > Andor
> >
> >
> >
> > On Wed, Mar 7, 2018 at 12:04 PM, Andor Molnar 
> wrote:
> >
> >> Okay, I dropped a mail on the user list to get some feedback.
> >>
> >>
> >> Regards,
> >> Andor
> >>
> >>
> >> On Thu, Feb 22, 2018 at 5:59 PM, Patrick Hunt  wrote:
> >>
> >>> Perhaps discuss on the user list as Flavio mentioned prior to calling a
> >>> vote? Has anyone looked at dependencies, is this consistent with what
> the
> >>> rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components,
> >>> Curator, etc...
> >>>
> >>> Regards,
> >>>
> >>> Patrick
> >>>
> >>> On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar 
> >>> wrote:
> >>>
> >>> > Is everybody happy with the plan that Tamaas suggested?
> >>> > Shall we start a vote?
> >>> >
> >>> > Andor
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes 
> >>> wrote:
> >>> >
> >>> > > Hi All,
> >>> > >
> >>> > > I totally support the idea of upgrading to Java 8 and I agree with
> >>> Abe
> >>> > that
> >>> > > we should not require different minimum versions of Java for the
> >>> client
> >>> > and
> >>> > > the server.
> >>> > > Also skipping the non-LTS versions sounds reasonable.
> >>> > >
> >>> > > Regards,
> >>> > > Mark
> >>> > >
> >>> > >
> >>> > > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes  >
> >>> > wrote:
> >>> > >
> >>> > > > Hi All,
> >>> > > >
> >>> > > > Just to add my 2 cents. // Might be five, I write long. :)
> >>> > > > Hope, you find valuable bits.
> >>> > > >
> >>> > > > As many of us I also hope that ZooKeeper 3.5 will be released
> soon.
> >>> > > > Until then most of the changes go into master and branch-3.5 too,
> >>> so I
> >>> > > > would keep them on the same Java version for code compatibility.
> >>> In the
> >>> > > > same time I'd be happy if it was Java 8.
> >>> > > >
> >>> > > > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old
> >>> Java
> >>> > > > version today.
> >>> > > > It was a perfect decision in 2014, when nobody expected ZK 3.5
> >>> coming
> >>> > so
> >>> > > > late, but things might be different four years later.
> >>> > > >
> >>> > > > Since we have to keep compatibility with Java 6 on branch-3.4 we
> >>> > already
> >>> > > > need manual changes when cherry picking into that branch. Not
> much
> >>> > > > difference if branch-3.5 is Java 8.
> >>> > > >
> >>> > > >
> >>> > > > As Flavio said changing branch-3.5 to Java 8 might cause issues
> for
> >>> > users
> >>> > > > already using ZK 3.5.x-beta.
> >>> > > > I totally agree with that concern, but using a beta state
> software
> >>> > means
> >>> > > > you accept the risk of facing changes.
> >>> > > > And Java 8 is four years old now, so we would not change to
> >>> bleeding
> >>> > > edge,
> >>> > > > which I guess nobody wanted.
> >>> > > >
> >>> > > >
> >>> > > > So what I would propose is the following:
> >>> > > >
> >>> > > >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS)
> >>> asap.
> >>> > > >- After releasing 3.5 GA and the next LTS Java version (Java
> 11
> >>> /
> >>> > > >18.9-LTS) gets released upgrade "master" branch to Java
> 11-LTS.
> >>> (
> >>> > > >http://www.oracle.com/technetwork/java/eol-135779.html)
> >>> > > >- I would not upgrade Java to a non-LTS version.
> >>> > > >
> >>> > > >
> >>> > > > What do you think about it?
> >>> > > >
> >>> > > > Thanks, Tamaas
> >>> > > >
> >>> > > >
> >>> > > > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira <
> f...@apache.org
> >>> >
> >>> > > wrote:
> >>> > > >
> >>> > > > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone
> >>> have a
> >>> > > > > different option? Otherwise, should we start a vote?
> >>> > > > >
> >>> > > > > -Flavio
> >>> > > > >
> >>> > > > >
> >>> > > > > > On 16 Feb 2018, at 21:28, Abraham Fine 
> >>> wrote:
> >>> > > > > >
> >>> > > > > > I'm a -1 on requiring different minimum versions of java for
> >>> the
> >>> > > client
> >>> > > > > and the server.  I think this has the potential to create a lot
> >>> of
> >>> > > > > confusion for users and contributors.
> >>> > > > > >
> >>> > > > > > I would support moving master (3.6) to java 8, I also think
> it
> >>> is
> >>> > > worth
> >>> > > > > considering 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

Silence probably means 'yes', so I start the vote now.

*Shall we upgrade the minimum required Java version to compile and run
ZooKeeper on 3.5 and master branches to Java 1.8?*

*Yes / No*

I vote for 'Yes'.

Regards,
Andor



On Mon, Mar 19, 2018 at 1:35 PM, Andor Molnar  wrote:

> From the responses on 'user' list, I think we are good to go.
>
> What do you think?
>
> Andor
>
>
>
> On Wed, Mar 7, 2018 at 12:04 PM, Andor Molnar  wrote:
>
>> Okay, I dropped a mail on the user list to get some feedback.
>>
>>
>> Regards,
>> Andor
>>
>>
>> On Thu, Feb 22, 2018 at 5:59 PM, Patrick Hunt  wrote:
>>
>>> Perhaps discuss on the user list as Flavio mentioned prior to calling a
>>> vote? Has anyone looked at dependencies, is this consistent with what the
>>> rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components,
>>> Curator, etc...
>>>
>>> Regards,
>>>
>>> Patrick
>>>
>>> On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar 
>>> wrote:
>>>
>>> > Is everybody happy with the plan that Tamaas suggested?
>>> > Shall we start a vote?
>>> >
>>> > Andor
>>> >
>>> >
>>> >
>>> > On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes 
>>> wrote:
>>> >
>>> > > Hi All,
>>> > >
>>> > > I totally support the idea of upgrading to Java 8 and I agree with
>>> Abe
>>> > that
>>> > > we should not require different minimum versions of Java for the
>>> client
>>> > and
>>> > > the server.
>>> > > Also skipping the non-LTS versions sounds reasonable.
>>> > >
>>> > > Regards,
>>> > > Mark
>>> > >
>>> > >
>>> > > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes 
>>> > wrote:
>>> > >
>>> > > > Hi All,
>>> > > >
>>> > > > Just to add my 2 cents. // Might be five, I write long. :)
>>> > > > Hope, you find valuable bits.
>>> > > >
>>> > > > As many of us I also hope that ZooKeeper 3.5 will be released soon.
>>> > > > Until then most of the changes go into master and branch-3.5 too,
>>> so I
>>> > > > would keep them on the same Java version for code compatibility.
>>> In the
>>> > > > same time I'd be happy if it was Java 8.
>>> > > >
>>> > > > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old
>>> Java
>>> > > > version today.
>>> > > > It was a perfect decision in 2014, when nobody expected ZK 3.5
>>> coming
>>> > so
>>> > > > late, but things might be different four years later.
>>> > > >
>>> > > > Since we have to keep compatibility with Java 6 on branch-3.4 we
>>> > already
>>> > > > need manual changes when cherry picking into that branch. Not much
>>> > > > difference if branch-3.5 is Java 8.
>>> > > >
>>> > > >
>>> > > > As Flavio said changing branch-3.5 to Java 8 might cause issues for
>>> > users
>>> > > > already using ZK 3.5.x-beta.
>>> > > > I totally agree with that concern, but using a beta state software
>>> > means
>>> > > > you accept the risk of facing changes.
>>> > > > And Java 8 is four years old now, so we would not change to
>>> bleeding
>>> > > edge,
>>> > > > which I guess nobody wanted.
>>> > > >
>>> > > >
>>> > > > So what I would propose is the following:
>>> > > >
>>> > > >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS)
>>> asap.
>>> > > >- After releasing 3.5 GA and the next LTS Java version (Java 11
>>> /
>>> > > >18.9-LTS) gets released upgrade "master" branch to Java 11-LTS.
>>> (
>>> > > >http://www.oracle.com/technetwork/java/eol-135779.html)
>>> > > >- I would not upgrade Java to a non-LTS version.
>>> > > >
>>> > > >
>>> > > > What do you think about it?
>>> > > >
>>> > > > Thanks, Tamaas
>>> > > >
>>> > > >
>>> > > > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira >> >
>>> > > wrote:
>>> > > >
>>> > > > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone
>>> have a
>>> > > > > different option? Otherwise, should we start a vote?
>>> > > > >
>>> > > > > -Flavio
>>> > > > >
>>> > > > >
>>> > > > > > On 16 Feb 2018, at 21:28, Abraham Fine 
>>> wrote:
>>> > > > > >
>>> > > > > > I'm a -1 on requiring different minimum versions of java for
>>> the
>>> > > client
>>> > > > > and the server.  I think this has the potential to create a lot
>>> of
>>> > > > > confusion for users and contributors.
>>> > > > > >
>>> > > > > > I would support moving master (3.6) to java 8, I also think it
>>> is
>>> > > worth
>>> > > > > considering moving to java 9. Given how long our release cycle
>>> tends
>>> > to
>>> > > > be
>>> > > > > I think targeting the latest and greatest this early in the
>>> > development
>>> > > > > cycle is reasonable.
>>> > > > > >
>>> > > > > > Thanks,
>>> > > > > > Abe
>>> > > > > >
>>> > > > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
>>> > > > > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
>>> > > > > >>
>>> > > > > >>> +1 for setting the Java8 requirement on server side.
>>> > > > > >>>
>>> > > > > >>> *Client side.*
>>> > > > > >>> I'd like the 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

>From the responses on 'user' list, I think we are good to go.

What do you think?

Andor



On Wed, Mar 7, 2018 at 12:04 PM, Andor Molnar  wrote:

> Okay, I dropped a mail on the user list to get some feedback.
>
>
> Regards,
> Andor
>
>
> On Thu, Feb 22, 2018 at 5:59 PM, Patrick Hunt  wrote:
>
>> Perhaps discuss on the user list as Flavio mentioned prior to calling a
>> vote? Has anyone looked at dependencies, is this consistent with what the
>> rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components,
>> Curator, etc...
>>
>> Regards,
>>
>> Patrick
>>
>> On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar  wrote:
>>
>> > Is everybody happy with the plan that Tamaas suggested?
>> > Shall we start a vote?
>> >
>> > Andor
>> >
>> >
>> >
>> > On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes 
>> wrote:
>> >
>> > > Hi All,
>> > >
>> > > I totally support the idea of upgrading to Java 8 and I agree with Abe
>> > that
>> > > we should not require different minimum versions of Java for the
>> client
>> > and
>> > > the server.
>> > > Also skipping the non-LTS versions sounds reasonable.
>> > >
>> > > Regards,
>> > > Mark
>> > >
>> > >
>> > > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes 
>> > wrote:
>> > >
>> > > > Hi All,
>> > > >
>> > > > Just to add my 2 cents. // Might be five, I write long. :)
>> > > > Hope, you find valuable bits.
>> > > >
>> > > > As many of us I also hope that ZooKeeper 3.5 will be released soon.
>> > > > Until then most of the changes go into master and branch-3.5 too,
>> so I
>> > > > would keep them on the same Java version for code compatibility. In
>> the
>> > > > same time I'd be happy if it was Java 8.
>> > > >
>> > > > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old
>> Java
>> > > > version today.
>> > > > It was a perfect decision in 2014, when nobody expected ZK 3.5
>> coming
>> > so
>> > > > late, but things might be different four years later.
>> > > >
>> > > > Since we have to keep compatibility with Java 6 on branch-3.4 we
>> > already
>> > > > need manual changes when cherry picking into that branch. Not much
>> > > > difference if branch-3.5 is Java 8.
>> > > >
>> > > >
>> > > > As Flavio said changing branch-3.5 to Java 8 might cause issues for
>> > users
>> > > > already using ZK 3.5.x-beta.
>> > > > I totally agree with that concern, but using a beta state software
>> > means
>> > > > you accept the risk of facing changes.
>> > > > And Java 8 is four years old now, so we would not change to bleeding
>> > > edge,
>> > > > which I guess nobody wanted.
>> > > >
>> > > >
>> > > > So what I would propose is the following:
>> > > >
>> > > >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS)
>> asap.
>> > > >- After releasing 3.5 GA and the next LTS Java version (Java 11 /
>> > > >18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
>> > > >http://www.oracle.com/technetwork/java/eol-135779.html)
>> > > >- I would not upgrade Java to a non-LTS version.
>> > > >
>> > > >
>> > > > What do you think about it?
>> > > >
>> > > > Thanks, Tamaas
>> > > >
>> > > >
>> > > > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira 
>> > > wrote:
>> > > >
>> > > > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have
>> a
>> > > > > different option? Otherwise, should we start a vote?
>> > > > >
>> > > > > -Flavio
>> > > > >
>> > > > >
>> > > > > > On 16 Feb 2018, at 21:28, Abraham Fine 
>> wrote:
>> > > > > >
>> > > > > > I'm a -1 on requiring different minimum versions of java for the
>> > > client
>> > > > > and the server.  I think this has the potential to create a lot of
>> > > > > confusion for users and contributors.
>> > > > > >
>> > > > > > I would support moving master (3.6) to java 8, I also think it
>> is
>> > > worth
>> > > > > considering moving to java 9. Given how long our release cycle
>> tends
>> > to
>> > > > be
>> > > > > I think targeting the latest and greatest this early in the
>> > development
>> > > > > cycle is reasonable.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Abe
>> > > > > >
>> > > > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
>> > > > > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
>> > > > > >>
>> > > > > >>> +1 for setting the Java8 requirement on server side.
>> > > > > >>>
>> > > > > >>> *Client side.*
>> > > > > >>> I'd like the idea of the setting the requirement on client
>> side
>> > too
>> > > > > without
>> > > > > >>> introducing anything Java8 specific. I'm not planning to use
>> > Java8
>> > > > > features
>> > > > > >>> right on, just thinking of opening the gates would be useful
>> in
>> > the
>> > > > > long
>> > > > > >>> run.
>> > > > > >>>
>> > > > > >>> Additionally, I don't see heavy development on the client
>> side.
>> > > Users
>> > > > > who
>> > > > > >>> are tightly coupled to Java7 are 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

Okay, I dropped a mail on the user list to get some feedback.


Regards,
Andor


On Thu, Feb 22, 2018 at 5:59 PM, Patrick Hunt  wrote:

> Perhaps discuss on the user list as Flavio mentioned prior to calling a
> vote? Has anyone looked at dependencies, is this consistent with what the
> rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components,
> Curator, etc...
>
> Regards,
>
> Patrick
>
> On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar  wrote:
>
> > Is everybody happy with the plan that Tamaas suggested?
> > Shall we start a vote?
> >
> > Andor
> >
> >
> >
> > On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes 
> wrote:
> >
> > > Hi All,
> > >
> > > I totally support the idea of upgrading to Java 8 and I agree with Abe
> > that
> > > we should not require different minimum versions of Java for the client
> > and
> > > the server.
> > > Also skipping the non-LTS versions sounds reasonable.
> > >
> > > Regards,
> > > Mark
> > >
> > >
> > > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes 
> > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Just to add my 2 cents. // Might be five, I write long. :)
> > > > Hope, you find valuable bits.
> > > >
> > > > As many of us I also hope that ZooKeeper 3.5 will be released soon.
> > > > Until then most of the changes go into master and branch-3.5 too, so
> I
> > > > would keep them on the same Java version for code compatibility. In
> the
> > > > same time I'd be happy if it was Java 8.
> > > >
> > > > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old
> Java
> > > > version today.
> > > > It was a perfect decision in 2014, when nobody expected ZK 3.5 coming
> > so
> > > > late, but things might be different four years later.
> > > >
> > > > Since we have to keep compatibility with Java 6 on branch-3.4 we
> > already
> > > > need manual changes when cherry picking into that branch. Not much
> > > > difference if branch-3.5 is Java 8.
> > > >
> > > >
> > > > As Flavio said changing branch-3.5 to Java 8 might cause issues for
> > users
> > > > already using ZK 3.5.x-beta.
> > > > I totally agree with that concern, but using a beta state software
> > means
> > > > you accept the risk of facing changes.
> > > > And Java 8 is four years old now, so we would not change to bleeding
> > > edge,
> > > > which I guess nobody wanted.
> > > >
> > > >
> > > > So what I would propose is the following:
> > > >
> > > >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
> > > >- After releasing 3.5 GA and the next LTS Java version (Java 11 /
> > > >18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
> > > >http://www.oracle.com/technetwork/java/eol-135779.html)
> > > >- I would not upgrade Java to a non-LTS version.
> > > >
> > > >
> > > > What do you think about it?
> > > >
> > > > Thanks, Tamaas
> > > >
> > > >
> > > > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira 
> > > wrote:
> > > >
> > > > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
> > > > > different option? Otherwise, should we start a vote?
> > > > >
> > > > > -Flavio
> > > > >
> > > > >
> > > > > > On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> > > > > >
> > > > > > I'm a -1 on requiring different minimum versions of java for the
> > > client
> > > > > and the server.  I think this has the potential to create a lot of
> > > > > confusion for users and contributors.
> > > > > >
> > > > > > I would support moving master (3.6) to java 8, I also think it is
> > > worth
> > > > > considering moving to java 9. Given how long our release cycle
> tends
> > to
> > > > be
> > > > > I think targeting the latest and greatest this early in the
> > development
> > > > > cycle is reasonable.
> > > > > >
> > > > > > Thanks,
> > > > > > Abe
> > > > > >
> > > > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> > > > > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> > > > > >>
> > > > > >>> +1 for setting the Java8 requirement on server side.
> > > > > >>>
> > > > > >>> *Client side.*
> > > > > >>> I'd like the idea of the setting the requirement on client side
> > too
> > > > > without
> > > > > >>> introducing anything Java8 specific. I'm not planning to use
> > Java8
> > > > > features
> > > > > >>> right on, just thinking of opening the gates would be useful in
> > the
> > > > > long
> > > > > >>> run.
> > > > > >>>
> > > > > >>> Additionally, I don't see heavy development on the client side.
> > > Users
> > > > > who
> > > > > >>> are tightly coupled to Java7 are still able to use existing
> > clients
> > > > as
> > > > > long
> > > > > >>> as we introduce something breaking which they're forced to
> > upgrade
> > > to
> > > > > for
> > > > > >>> whatever reason. I'm not sure what are the odds of that to
> > happen.
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> My two cents
> > > > > >> Actually 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Patrick Hunt]

Perhaps discuss on the user list as Flavio mentioned prior to calling a
vote? Has anyone looked at dependencies, is this consistent with what the
rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components,
Curator, etc...

Regards,

Patrick

On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar  wrote:

> Is everybody happy with the plan that Tamaas suggested?
> Shall we start a vote?
>
> Andor
>
>
>
> On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes  wrote:
>
> > Hi All,
> >
> > I totally support the idea of upgrading to Java 8 and I agree with Abe
> that
> > we should not require different minimum versions of Java for the client
> and
> > the server.
> > Also skipping the non-LTS versions sounds reasonable.
> >
> > Regards,
> > Mark
> >
> >
> > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes 
> wrote:
> >
> > > Hi All,
> > >
> > > Just to add my 2 cents. // Might be five, I write long. :)
> > > Hope, you find valuable bits.
> > >
> > > As many of us I also hope that ZooKeeper 3.5 will be released soon.
> > > Until then most of the changes go into master and branch-3.5 too, so I
> > > would keep them on the same Java version for code compatibility. In the
> > > same time I'd be happy if it was Java 8.
> > >
> > > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java
> > > version today.
> > > It was a perfect decision in 2014, when nobody expected ZK 3.5 coming
> so
> > > late, but things might be different four years later.
> > >
> > > Since we have to keep compatibility with Java 6 on branch-3.4 we
> already
> > > need manual changes when cherry picking into that branch. Not much
> > > difference if branch-3.5 is Java 8.
> > >
> > >
> > > As Flavio said changing branch-3.5 to Java 8 might cause issues for
> users
> > > already using ZK 3.5.x-beta.
> > > I totally agree with that concern, but using a beta state software
> means
> > > you accept the risk of facing changes.
> > > And Java 8 is four years old now, so we would not change to bleeding
> > edge,
> > > which I guess nobody wanted.
> > >
> > >
> > > So what I would propose is the following:
> > >
> > >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
> > >- After releasing 3.5 GA and the next LTS Java version (Java 11 /
> > >18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
> > >http://www.oracle.com/technetwork/java/eol-135779.html)
> > >- I would not upgrade Java to a non-LTS version.
> > >
> > >
> > > What do you think about it?
> > >
> > > Thanks, Tamaas
> > >
> > >
> > > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira 
> > wrote:
> > >
> > > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
> > > > different option? Otherwise, should we start a vote?
> > > >
> > > > -Flavio
> > > >
> > > >
> > > > > On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> > > > >
> > > > > I'm a -1 on requiring different minimum versions of java for the
> > client
> > > > and the server.  I think this has the potential to create a lot of
> > > > confusion for users and contributors.
> > > > >
> > > > > I would support moving master (3.6) to java 8, I also think it is
> > worth
> > > > considering moving to java 9. Given how long our release cycle tends
> to
> > > be
> > > > I think targeting the latest and greatest this early in the
> development
> > > > cycle is reasonable.
> > > > >
> > > > > Thanks,
> > > > > Abe
> > > > >
> > > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> > > > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> > > > >>
> > > > >>> +1 for setting the Java8 requirement on server side.
> > > > >>>
> > > > >>> *Client side.*
> > > > >>> I'd like the idea of the setting the requirement on client side
> too
> > > > without
> > > > >>> introducing anything Java8 specific. I'm not planning to use
> Java8
> > > > features
> > > > >>> right on, just thinking of opening the gates would be useful in
> the
> > > > long
> > > > >>> run.
> > > > >>>
> > > > >>> Additionally, I don't see heavy development on the client side.
> > Users
> > > > who
> > > > >>> are tightly coupled to Java7 are still able to use existing
> clients
> > > as
> > > > long
> > > > >>> as we introduce something breaking which they're forced to
> upgrade
> > to
> > > > for
> > > > >>> whatever reason. I'm not sure what are the odds of that to
> happen.
> > > > >>>
> > > > >>
> > > > >>
> > > > >> My two cents
> > > > >> Actually ZooKeeper is distributed as a single JAR which contains
> > both
> > > > >> server and client side code, requiring Java 7 for the client and
> > Java
> > > 8
> > > > for
> > > > >> the server will require a new way of packaging the artifacts and
> > > > building
> > > > >> the project (and this will require separating client side and
> server
> > > > side
> > > > >> code base).
> > > > >> Maybe I am missing something.
> > > > >>
> > > > >>
> > > > 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

Is everybody happy with the plan that Tamaas suggested?
Shall we start a vote?

Andor



On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes  wrote:

> Hi All,
>
> I totally support the idea of upgrading to Java 8 and I agree with Abe that
> we should not require different minimum versions of Java for the client and
> the server.
> Also skipping the non-LTS versions sounds reasonable.
>
> Regards,
> Mark
>
>
> On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes  wrote:
>
> > Hi All,
> >
> > Just to add my 2 cents. // Might be five, I write long. :)
> > Hope, you find valuable bits.
> >
> > As many of us I also hope that ZooKeeper 3.5 will be released soon.
> > Until then most of the changes go into master and branch-3.5 too, so I
> > would keep them on the same Java version for code compatibility. In the
> > same time I'd be happy if it was Java 8.
> >
> > ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java
> > version today.
> > It was a perfect decision in 2014, when nobody expected ZK 3.5 coming so
> > late, but things might be different four years later.
> >
> > Since we have to keep compatibility with Java 6 on branch-3.4 we already
> > need manual changes when cherry picking into that branch. Not much
> > difference if branch-3.5 is Java 8.
> >
> >
> > As Flavio said changing branch-3.5 to Java 8 might cause issues for users
> > already using ZK 3.5.x-beta.
> > I totally agree with that concern, but using a beta state software means
> > you accept the risk of facing changes.
> > And Java 8 is four years old now, so we would not change to bleeding
> edge,
> > which I guess nobody wanted.
> >
> >
> > So what I would propose is the following:
> >
> >- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
> >- After releasing 3.5 GA and the next LTS Java version (Java 11 /
> >18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
> >http://www.oracle.com/technetwork/java/eol-135779.html)
> >- I would not upgrade Java to a non-LTS version.
> >
> >
> > What do you think about it?
> >
> > Thanks, Tamaas
> >
> >
> > On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira 
> wrote:
> >
> > > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
> > > different option? Otherwise, should we start a vote?
> > >
> > > -Flavio
> > >
> > >
> > > > On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> > > >
> > > > I'm a -1 on requiring different minimum versions of java for the
> client
> > > and the server.  I think this has the potential to create a lot of
> > > confusion for users and contributors.
> > > >
> > > > I would support moving master (3.6) to java 8, I also think it is
> worth
> > > considering moving to java 9. Given how long our release cycle tends to
> > be
> > > I think targeting the latest and greatest this early in the development
> > > cycle is reasonable.
> > > >
> > > > Thanks,
> > > > Abe
> > > >
> > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> > > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> > > >>
> > > >>> +1 for setting the Java8 requirement on server side.
> > > >>>
> > > >>> *Client side.*
> > > >>> I'd like the idea of the setting the requirement on client side too
> > > without
> > > >>> introducing anything Java8 specific. I'm not planning to use Java8
> > > features
> > > >>> right on, just thinking of opening the gates would be useful in the
> > > long
> > > >>> run.
> > > >>>
> > > >>> Additionally, I don't see heavy development on the client side.
> Users
> > > who
> > > >>> are tightly coupled to Java7 are still able to use existing clients
> > as
> > > long
> > > >>> as we introduce something breaking which they're forced to upgrade
> to
> > > for
> > > >>> whatever reason. I'm not sure what are the odds of that to happen.
> > > >>>
> > > >>
> > > >>
> > > >> My two cents
> > > >> Actually ZooKeeper is distributed as a single JAR which contains
> both
> > > >> server and client side code, requiring Java 7 for the client and
> Java
> > 8
> > > for
> > > >> the server will require a new way of packaging the artifacts and
> > > building
> > > >> the project (and this will require separating client side and server
> > > side
> > > >> code base).
> > > >> Maybe I am missing something.
> > > >>
> > > >>
> > > >> Enrico
> > > >>
> > > >>
> > > >>>
> > > >>> Andor
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira  >
> > > wrote:
> > > >>>
> > >  We have this section in the admin doc that talks about the system
> > >  requirements:
> > > 
> > >  https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.
> > html#sc_
> > >  requiredSoftware  > >  zookeeperAdmin.html#sc_requiredSoftware>
> > > 
> > >  If we change, then we have to update that section. Specifically
> > about
> > >  

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Mark Fenes]

Hi All,

I totally support the idea of upgrading to Java 8 and I agree with Abe that
we should not require different minimum versions of Java for the client and
the server.
Also skipping the non-LTS versions sounds reasonable.

Regards,
Mark


On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes  wrote:

> Hi All,
>
> Just to add my 2 cents. // Might be five, I write long. :)
> Hope, you find valuable bits.
>
> As many of us I also hope that ZooKeeper 3.5 will be released soon.
> Until then most of the changes go into master and branch-3.5 too, so I
> would keep them on the same Java version for code compatibility. In the
> same time I'd be happy if it was Java 8.
>
> ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java
> version today.
> It was a perfect decision in 2014, when nobody expected ZK 3.5 coming so
> late, but things might be different four years later.
>
> Since we have to keep compatibility with Java 6 on branch-3.4 we already
> need manual changes when cherry picking into that branch. Not much
> difference if branch-3.5 is Java 8.
>
>
> As Flavio said changing branch-3.5 to Java 8 might cause issues for users
> already using ZK 3.5.x-beta.
> I totally agree with that concern, but using a beta state software means
> you accept the risk of facing changes.
> And Java 8 is four years old now, so we would not change to bleeding edge,
> which I guess nobody wanted.
>
>
> So what I would propose is the following:
>
>- Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
>- After releasing 3.5 GA and the next LTS Java version (Java 11 /
>18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
>http://www.oracle.com/technetwork/java/eol-135779.html)
>- I would not upgrade Java to a non-LTS version.
>
>
> What do you think about it?
>
> Thanks, Tamaas
>
>
> On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira  wrote:
>
> > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
> > different option? Otherwise, should we start a vote?
> >
> > -Flavio
> >
> >
> > > On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> > >
> > > I'm a -1 on requiring different minimum versions of java for the client
> > and the server.  I think this has the potential to create a lot of
> > confusion for users and contributors.
> > >
> > > I would support moving master (3.6) to java 8, I also think it is worth
> > considering moving to java 9. Given how long our release cycle tends to
> be
> > I think targeting the latest and greatest this early in the development
> > cycle is reasonable.
> > >
> > > Thanks,
> > > Abe
> > >
> > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> > >>
> > >>> +1 for setting the Java8 requirement on server side.
> > >>>
> > >>> *Client side.*
> > >>> I'd like the idea of the setting the requirement on client side too
> > without
> > >>> introducing anything Java8 specific. I'm not planning to use Java8
> > features
> > >>> right on, just thinking of opening the gates would be useful in the
> > long
> > >>> run.
> > >>>
> > >>> Additionally, I don't see heavy development on the client side. Users
> > who
> > >>> are tightly coupled to Java7 are still able to use existing clients
> as
> > long
> > >>> as we introduce something breaking which they're forced to upgrade to
> > for
> > >>> whatever reason. I'm not sure what are the odds of that to happen.
> > >>>
> > >>
> > >>
> > >> My two cents
> > >> Actually ZooKeeper is distributed as a single JAR which contains both
> > >> server and client side code, requiring Java 7 for the client and Java
> 8
> > for
> > >> the server will require a new way of packaging the artifacts and
> > building
> > >> the project (and this will require separating client side and server
> > side
> > >> code base).
> > >> Maybe I am missing something.
> > >>
> > >>
> > >> Enrico
> > >>
> > >>
> > >>>
> > >>> Andor
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira 
> > wrote:
> > >>>
> >  We have this section in the admin doc that talks about the system
> >  requirements:
> > 
> >  https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.
> html#sc_
> >  requiredSoftware  >  zookeeperAdmin.html#sc_requiredSoftware>
> > 
> >  If we change, then we have to update that section. Specifically
> about
> >  client and server, I'd think that there is no problem with requiring
> > >>> Java 8
> >  on the server. The potential concern is with the client as it
> affects
> >  applications that build against it. It would be best to not force
> >  applications to upgrade themselves. Looking at the compatibility
> guide
> > >>> for
> >  Java 8:
> > 
> >  http://www.oracle.com/technetwork/java/javase/8-
> >  

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Flavio Junqueira]

Hi Tamaas,

Thanks for the feedback. I'm fine with the plan. We might want to send a 
message to the user list once we reach some agreement here to assess whether 
users have a concern.

-Flavio

> On 20 Feb 2018, at 20:49, Tamás Pénzes  wrote:
> 
> Hi All,
> 
> Just to add my 2 cents. // Might be five, I write long. :)
> Hope, you find valuable bits.
> 
> As many of us I also hope that ZooKeeper 3.5 will be released soon.
> Until then most of the changes go into master and branch-3.5 too, so I
> would keep them on the same Java version for code compatibility. In the
> same time I'd be happy if it was Java 8.
> 
> ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java
> version today.
> It was a perfect decision in 2014, when nobody expected ZK 3.5 coming so
> late, but things might be different four years later.
> 
> Since we have to keep compatibility with Java 6 on branch-3.4 we already
> need manual changes when cherry picking into that branch. Not much
> difference if branch-3.5 is Java 8.
> 
> 
> As Flavio said changing branch-3.5 to Java 8 might cause issues for users
> already using ZK 3.5.x-beta.
> I totally agree with that concern, but using a beta state software means
> you accept the risk of facing changes.
> And Java 8 is four years old now, so we would not change to bleeding edge,
> which I guess nobody wanted.
> 
> 
> So what I would propose is the following:
> 
>   - Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
>   - After releasing 3.5 GA and the next LTS Java version (Java 11 /
>   18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
>   http://www.oracle.com/technetwork/java/eol-135779.html)
>   - I would not upgrade Java to a non-LTS version.
> 
> 
> What do you think about it?
> 
> Thanks, Tamaas
> 
> 
> On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira  wrote:
> 
>> I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
>> different option? Otherwise, should we start a vote?
>> 
>> -Flavio
>> 
>> 
>>> On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
>>> 
>>> I'm a -1 on requiring different minimum versions of java for the client
>> and the server.  I think this has the potential to create a lot of
>> confusion for users and contributors.
>>> 
>>> I would support moving master (3.6) to java 8, I also think it is worth
>> considering moving to java 9. Given how long our release cycle tends to be
>> I think targeting the latest and greatest this early in the development
>> cycle is reasonable.
>>> 
>>> Thanks,
>>> Abe
>>> 
>>> On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
 2018-02-16 14:20 GMT+01:00 Andor Molnar :
 
> +1 for setting the Java8 requirement on server side.
> 
> *Client side.*
> I'd like the idea of the setting the requirement on client side too
>> without
> introducing anything Java8 specific. I'm not planning to use Java8
>> features
> right on, just thinking of opening the gates would be useful in the
>> long
> run.
> 
> Additionally, I don't see heavy development on the client side. Users
>> who
> are tightly coupled to Java7 are still able to use existing clients as
>> long
> as we introduce something breaking which they're forced to upgrade to
>> for
> whatever reason. I'm not sure what are the odds of that to happen.
> 
 
 
 My two cents
 Actually ZooKeeper is distributed as a single JAR which contains both
 server and client side code, requiring Java 7 for the client and Java 8
>> for
 the server will require a new way of packaging the artifacts and
>> building
 the project (and this will require separating client side and server
>> side
 code base).
 Maybe I am missing something.
 
 
 Enrico
 
 
> 
> Andor
> 
> 
> 
> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira 
>> wrote:
> 
>> We have this section in the admin doc that talks about the system
>> requirements:
>> 
>> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
>> requiredSoftware > zookeeperAdmin.html#sc_requiredSoftware>
>> 
>> If we change, then we have to update that section. Specifically about
>> client and server, I'd think that there is no problem with requiring
> Java 8
>> on the server. The potential concern is with the client as it affects
>> applications that build against it. It would be best to not force
>> applications to upgrade themselves. Looking at the compatibility guide
> for
>> Java 8:
>> 
>> http://www.oracle.com/technetwork/java/javase/8-
>> compatibility-guide-2156366.html > technetwork/java/javase/8-compatibility-guide-2156366.html>
>> 
>> The risk is that an application is strictly using Java 7 because of

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Tamás Pénzes]

Hi All,

Just to add my 2 cents. // Might be five, I write long. :)
Hope, you find valuable bits.

As many of us I also hope that ZooKeeper 3.5 will be released soon.
Until then most of the changes go into master and branch-3.5 too, so I
would keep them on the same Java version for code compatibility. In the
same time I'd be happy if it was Java 8.

ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java
version today.
It was a perfect decision in 2014, when nobody expected ZK 3.5 coming so
late, but things might be different four years later.

Since we have to keep compatibility with Java 6 on branch-3.4 we already
need manual changes when cherry picking into that branch. Not much
difference if branch-3.5 is Java 8.


As Flavio said changing branch-3.5 to Java 8 might cause issues for users
already using ZK 3.5.x-beta.
I totally agree with that concern, but using a beta state software means
you accept the risk of facing changes.
And Java 8 is four years old now, so we would not change to bleeding edge,
which I guess nobody wanted.


So what I would propose is the following:

   - Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap.
   - After releasing 3.5 GA and the next LTS Java version (Java 11 /
   18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. (
   http://www.oracle.com/technetwork/java/eol-135779.html)
   - I would not upgrade Java to a non-LTS version.


What do you think about it?

Thanks, Tamaas


On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira  wrote:

> I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a
> different option? Otherwise, should we start a vote?
>
> -Flavio
>
>
> > On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> >
> > I'm a -1 on requiring different minimum versions of java for the client
> and the server.  I think this has the potential to create a lot of
> confusion for users and contributors.
> >
> > I would support moving master (3.6) to java 8, I also think it is worth
> considering moving to java 9. Given how long our release cycle tends to be
> I think targeting the latest and greatest this early in the development
> cycle is reasonable.
> >
> > Thanks,
> > Abe
> >
> > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> >> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> >>
> >>> +1 for setting the Java8 requirement on server side.
> >>>
> >>> *Client side.*
> >>> I'd like the idea of the setting the requirement on client side too
> without
> >>> introducing anything Java8 specific. I'm not planning to use Java8
> features
> >>> right on, just thinking of opening the gates would be useful in the
> long
> >>> run.
> >>>
> >>> Additionally, I don't see heavy development on the client side. Users
> who
> >>> are tightly coupled to Java7 are still able to use existing clients as
> long
> >>> as we introduce something breaking which they're forced to upgrade to
> for
> >>> whatever reason. I'm not sure what are the odds of that to happen.
> >>>
> >>
> >>
> >> My two cents
> >> Actually ZooKeeper is distributed as a single JAR which contains both
> >> server and client side code, requiring Java 7 for the client and Java 8
> for
> >> the server will require a new way of packaging the artifacts and
> building
> >> the project (and this will require separating client side and server
> side
> >> code base).
> >> Maybe I am missing something.
> >>
> >>
> >> Enrico
> >>
> >>
> >>>
> >>> Andor
> >>>
> >>>
> >>>
> >>> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira 
> wrote:
> >>>
>  We have this section in the admin doc that talks about the system
>  requirements:
> 
>  https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
>  requiredSoftware   zookeeperAdmin.html#sc_requiredSoftware>
> 
>  If we change, then we have to update that section. Specifically about
>  client and server, I'd think that there is no problem with requiring
> >>> Java 8
>  on the server. The potential concern is with the client as it affects
>  applications that build against it. It would be best to not force
>  applications to upgrade themselves. Looking at the compatibility guide
> >>> for
>  Java 8:
> 
>  http://www.oracle.com/technetwork/java/javase/8-
>  compatibility-guide-2156366.html   technetwork/java/javase/8-compatibility-guide-2156366.html>
> 
>  The risk is that an application is strictly using Java 7 because of
> some
>  incompatibility listed in that guide, in which case, it wouldn't be
> able
> >>> to
>  compile the ZK client assuming we get it to use some Java 8 construct.
> >>> One
>  option is that we raise the requirement to Java 8, but we do no really
>  introduce anything that breaks compatibility for the next version.
> Users
>  should take this as a warning that they need 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Flavio Junqueira]

I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a different 
option? Otherwise, should we start a vote?

-Flavio


> On 16 Feb 2018, at 21:28, Abraham Fine  wrote:
> 
> I'm a -1 on requiring different minimum versions of java for the client and 
> the server.  I think this has the potential to create a lot of confusion for 
> users and contributors. 
> 
> I would support moving master (3.6) to java 8, I also think it is worth 
> considering moving to java 9. Given how long our release cycle tends to be I 
> think targeting the latest and greatest this early in the development cycle 
> is reasonable.
> 
> Thanks,
> Abe
> 
> On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
>> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
>> 
>>> +1 for setting the Java8 requirement on server side.
>>> 
>>> *Client side.*
>>> I'd like the idea of the setting the requirement on client side too without
>>> introducing anything Java8 specific. I'm not planning to use Java8 features
>>> right on, just thinking of opening the gates would be useful in the long
>>> run.
>>> 
>>> Additionally, I don't see heavy development on the client side. Users who
>>> are tightly coupled to Java7 are still able to use existing clients as long
>>> as we introduce something breaking which they're forced to upgrade to for
>>> whatever reason. I'm not sure what are the odds of that to happen.
>>> 
>> 
>> 
>> My two cents
>> Actually ZooKeeper is distributed as a single JAR which contains both
>> server and client side code, requiring Java 7 for the client and Java 8 for
>> the server will require a new way of packaging the artifacts and building
>> the project (and this will require separating client side and server side
>> code base).
>> Maybe I am missing something.
>> 
>> 
>> Enrico
>> 
>> 
>>> 
>>> Andor
>>> 
>>> 
>>> 
>>> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira  wrote:
>>> 
 We have this section in the admin doc that talks about the system
 requirements:
 
 https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
 requiredSoftware 
 
 If we change, then we have to update that section. Specifically about
 client and server, I'd think that there is no problem with requiring
>>> Java 8
 on the server. The potential concern is with the client as it affects
 applications that build against it. It would be best to not force
 applications to upgrade themselves. Looking at the compatibility guide
>>> for
 Java 8:
 
 http://www.oracle.com/technetwork/java/javase/8-
 compatibility-guide-2156366.html 
 
 The risk is that an application is strictly using Java 7 because of some
 incompatibility listed in that guide, in which case, it wouldn't be able
>>> to
 compile the ZK client assuming we get it to use some Java 8 construct.
>>> One
 option is that we raise the requirement to Java 8, but we do no really
 introduce anything that breaks compatibility for the next version. Users
 should take this as a warning that they need to migrate to Java 8. I'm
>>> not
 sure this makes the situation any better, though. Another option is that
>>> we
 set a release to be the one in which we migrate and let everyone know
>>> that
 they need to migrate.
 
 -Flavio
 
 
> On 16 Feb 2018, at 12:05, Andor Molnar  wrote:
> 
> Hi all,
> 
> I think it would be nice to draw a line at branch-3.5 and target Java
> version 8 onwards. It seems to be a good opportunity for the upgrade
 before
> we release a stable version of 3.5.
> 
> The benefit would be the ability to use new features of Java 8 in the
 code:
> 
> Do think it's feasible?
> 
> Regards,
> Andor
 
 
>>> 

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Abraham Fine]

I'm a -1 on requiring different minimum versions of java for the client and the 
server.  I think this has the potential to create a lot of confusion for users 
and contributors. 

I would support moving master (3.6) to java 8, I also think it is worth 
considering moving to java 9. Given how long our release cycle tends to be I 
think targeting the latest and greatest this early in the development cycle is 
reasonable.

Thanks,
Abe

On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote:
> 2018-02-16 14:20 GMT+01:00 Andor Molnar :
> 
> > +1 for setting the Java8 requirement on server side.
> >
> > *Client side.*
> > I'd like the idea of the setting the requirement on client side too without
> > introducing anything Java8 specific. I'm not planning to use Java8 features
> > right on, just thinking of opening the gates would be useful in the long
> > run.
> >
> > Additionally, I don't see heavy development on the client side. Users who
> > are tightly coupled to Java7 are still able to use existing clients as long
> > as we introduce something breaking which they're forced to upgrade to for
> > whatever reason. I'm not sure what are the odds of that to happen.
> >
> 
> 
> My two cents
> Actually ZooKeeper is distributed as a single JAR which contains both
> server and client side code, requiring Java 7 for the client and Java 8 for
> the server will require a new way of packaging the artifacts and building
> the project (and this will require separating client side and server side
> code base).
> Maybe I am missing something.
> 
> 
> Enrico
> 
> 
> >
> > Andor
> >
> >
> >
> > On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira  wrote:
> >
> > > We have this section in the admin doc that talks about the system
> > > requirements:
> > >
> > > https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
> > > requiredSoftware  > > zookeeperAdmin.html#sc_requiredSoftware>
> > >
> > > If we change, then we have to update that section. Specifically about
> > > client and server, I'd think that there is no problem with requiring
> > Java 8
> > > on the server. The potential concern is with the client as it affects
> > > applications that build against it. It would be best to not force
> > > applications to upgrade themselves. Looking at the compatibility guide
> > for
> > > Java 8:
> > >
> > > http://www.oracle.com/technetwork/java/javase/8-
> > > compatibility-guide-2156366.html  > > technetwork/java/javase/8-compatibility-guide-2156366.html>
> > >
> > > The risk is that an application is strictly using Java 7 because of some
> > > incompatibility listed in that guide, in which case, it wouldn't be able
> > to
> > > compile the ZK client assuming we get it to use some Java 8 construct.
> > One
> > > option is that we raise the requirement to Java 8, but we do no really
> > > introduce anything that breaks compatibility for the next version. Users
> > > should take this as a warning that they need to migrate to Java 8. I'm
> > not
> > > sure this makes the situation any better, though. Another option is that
> > we
> > > set a release to be the one in which we migrate and let everyone know
> > that
> > > they need to migrate.
> > >
> > > -Flavio
> > >
> > >
> > > > On 16 Feb 2018, at 12:05, Andor Molnar  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I think it would be nice to draw a line at branch-3.5 and target Java
> > > > version 8 onwards. It seems to be a good opportunity for the upgrade
> > > before
> > > > we release a stable version of 3.5.
> > > >
> > > > The benefit would be the ability to use new features of Java 8 in the
> > > code:
> > > >
> > > > Do think it's feasible?
> > > >
> > > > Regards,
> > > > Andor
> > >
> > >
> >

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Enrico Olivelli]

2018-02-16 14:20 GMT+01:00 Andor Molnar :

> +1 for setting the Java8 requirement on server side.
>
> *Client side.*
> I'd like the idea of the setting the requirement on client side too without
> introducing anything Java8 specific. I'm not planning to use Java8 features
> right on, just thinking of opening the gates would be useful in the long
> run.
>
> Additionally, I don't see heavy development on the client side. Users who
> are tightly coupled to Java7 are still able to use existing clients as long
> as we introduce something breaking which they're forced to upgrade to for
> whatever reason. I'm not sure what are the odds of that to happen.
>


My two cents
Actually ZooKeeper is distributed as a single JAR which contains both
server and client side code, requiring Java 7 for the client and Java 8 for
the server will require a new way of packaging the artifacts and building
the project (and this will require separating client side and server side
code base).
Maybe I am missing something.


Enrico


>
> Andor
>
>
>
> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira  wrote:
>
> > We have this section in the admin doc that talks about the system
> > requirements:
> >
> > https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
> > requiredSoftware  > zookeeperAdmin.html#sc_requiredSoftware>
> >
> > If we change, then we have to update that section. Specifically about
> > client and server, I'd think that there is no problem with requiring
> Java 8
> > on the server. The potential concern is with the client as it affects
> > applications that build against it. It would be best to not force
> > applications to upgrade themselves. Looking at the compatibility guide
> for
> > Java 8:
> >
> > http://www.oracle.com/technetwork/java/javase/8-
> > compatibility-guide-2156366.html  > technetwork/java/javase/8-compatibility-guide-2156366.html>
> >
> > The risk is that an application is strictly using Java 7 because of some
> > incompatibility listed in that guide, in which case, it wouldn't be able
> to
> > compile the ZK client assuming we get it to use some Java 8 construct.
> One
> > option is that we raise the requirement to Java 8, but we do no really
> > introduce anything that breaks compatibility for the next version. Users
> > should take this as a warning that they need to migrate to Java 8. I'm
> not
> > sure this makes the situation any better, though. Another option is that
> we
> > set a release to be the one in which we migrate and let everyone know
> that
> > they need to migrate.
> >
> > -Flavio
> >
> >
> > > On 16 Feb 2018, at 12:05, Andor Molnar  wrote:
> > >
> > > Hi all,
> > >
> > > I think it would be nice to draw a line at branch-3.5 and target Java
> > > version 8 onwards. It seems to be a good opportunity for the upgrade
> > before
> > > we release a stable version of 3.5.
> > >
> > > The benefit would be the ability to use new features of Java 8 in the
> > code:
> > >
> > > Do think it's feasible?
> > >
> > > Regards,
> > > Andor
> >
> >
>

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

+1 for setting the Java8 requirement on server side.

*Client side.*
I'd like the idea of the setting the requirement on client side too without
introducing anything Java8 specific. I'm not planning to use Java8 features
right on, just thinking of opening the gates would be useful in the long
run.

Additionally, I don't see heavy development on the client side. Users who
are tightly coupled to Java7 are still able to use existing clients as long
as we introduce something breaking which they're forced to upgrade to for
whatever reason. I'm not sure what are the odds of that to happen.

Andor



On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira  wrote:

> We have this section in the admin doc that talks about the system
> requirements:
>
> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_
> requiredSoftware  zookeeperAdmin.html#sc_requiredSoftware>
>
> If we change, then we have to update that section. Specifically about
> client and server, I'd think that there is no problem with requiring Java 8
> on the server. The potential concern is with the client as it affects
> applications that build against it. It would be best to not force
> applications to upgrade themselves. Looking at the compatibility guide for
> Java 8:
>
> http://www.oracle.com/technetwork/java/javase/8-
> compatibility-guide-2156366.html  technetwork/java/javase/8-compatibility-guide-2156366.html>
>
> The risk is that an application is strictly using Java 7 because of some
> incompatibility listed in that guide, in which case, it wouldn't be able to
> compile the ZK client assuming we get it to use some Java 8 construct. One
> option is that we raise the requirement to Java 8, but we do no really
> introduce anything that breaks compatibility for the next version. Users
> should take this as a warning that they need to migrate to Java 8. I'm not
> sure this makes the situation any better, though. Another option is that we
> set a release to be the one in which we migrate and let everyone know that
> they need to migrate.
>
> -Flavio
>
>
> > On 16 Feb 2018, at 12:05, Andor Molnar  wrote:
> >
> > Hi all,
> >
> > I think it would be nice to draw a line at branch-3.5 and target Java
> > version 8 onwards. It seems to be a good opportunity for the upgrade
> before
> > we release a stable version of 3.5.
> >
> > The benefit would be the ability to use new features of Java 8 in the
> code:
> >
> > Do think it's feasible?
> >
> > Regards,
> > Andor
>
>

Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Flavio Junqueira]

We have this section in the admin doc that talks about the system requirements:

https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_requiredSoftware
 


If we change, then we have to update that section. Specifically about client 
and server, I'd think that there is no problem with requiring Java 8 on the 
server. The potential concern is with the client as it affects applications 
that build against it. It would be best to not force applications to upgrade 
themselves. Looking at the compatibility guide for Java 8:

http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
 


The risk is that an application is strictly using Java 7 because of some 
incompatibility listed in that guide, in which case, it wouldn't be able to 
compile the ZK client assuming we get it to use some Java 8 construct. One 
option is that we raise the requirement to Java 8, but we do no really 
introduce anything that breaks compatibility for the next version. Users should 
take this as a warning that they need to migrate to Java 8. I'm not sure this 
makes the situation any better, though. Another option is that we set a release 
to be the one in which we migrate and let everyone know that they need to 
migrate.

-Flavio


> On 16 Feb 2018, at 12:05, Andor Molnar  wrote:
> 
> Hi all,
> 
> I think it would be nice to draw a line at branch-3.5 and target Java
> version 8 onwards. It seems to be a good opportunity for the upgrade before
> we release a stable version of 3.5.
> 
> The benefit would be the ability to use new features of Java 8 in the code:
> 
> Do think it's feasible?
> 
> Regards,
> Andor

[SUGGESTION] Target branches 3.5 and master (3.6) to Java 8

[Andor Molnar]

Hi all,

I think it would be nice to draw a line at branch-3.5 and target Java
version 8 onwards. It seems to be a good opportunity for the upgrade before
we release a stable version of 3.5.

The benefit would be the ability to use new features of Java 8 in the code:

Do think it's feasible?

Regards,
Andor