zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Pénzes <tam...@cloudera.com>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Tue, 20 Feb 2018 19:49:01 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message