zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Fenes <mfe...@cloudera.com>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Wed, 21 Feb 2018 22:34:43 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message