zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <...@apache.org>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Wed, 21 Feb 2018 20:57:06 GMT
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 <tamaas@cloudera.com> 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 <fpj@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 <afine@apache.org> 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 <andor@cloudera.com>:
>>>> 
>>>>> +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 <fpj@apache.org>
>> 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 <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 <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 <andor@cloudera.com>
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
>>>>>> 
>>>>>> 
>>>>> 
>> 
>> 
> 
> 
> -- 
> 
> *Tamás **Pénzes* | Engineering Manager
> e. tamaas@cloudera.com
> cloudera.com <http://www.cloudera.com/>
> 
> [image: Cloudera] <http://www.cloudera.com/>
> 
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
> on LinkedIn] <https://www.linkedin.com/company/cloudera>
> ------------------------------


Mime
View raw message