zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@cloudera.com>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Thu, 22 Mar 2018 17:43:26 GMT
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 <andor@cloudera.com> 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 <andor@cloudera.com> 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 <phunt@apache.org> 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 <andor@cloudera.com>
>>> 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 <mfenes@cloudera.com>
>>> 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 <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