Upgrade required Java version to 1.8 on 3.5+

[Andor Molnar <an...@cloudera.com>]

Hi ZooKeeper users,

There's an ongoing discussion on the dev list about upgrading the required
Java version to 1.8 on trunk and 3.5 branches.

We'd like to get some feedback from a bigger audience if anybody or any
other component that is dependent on ZooKeeper has any concerns or
objections against the change?

I've quickly checked some of the major components that are heavy Zk clients:

Hadoop/HDFS = 1.8 required
HBase = 1.8 required
Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
Hive = 1.8 required
Curator = 1.7 required (has 1.8-only async module to take advantage of Java
lambdas)
Solr  = 1.8

As always, your feedback is much appreciated.

Thanks,
Andor

Re: Upgrade required Java version to 1.8 on 3.5+

[Andor Molnar <an...@cloudera.com>]

Hi Zk users,

Please be aware that ZooKeeper master and 3.5 branches have been upgraded
to Java 8.
Prior Java versions are no longer supported on these branches.

(Thanks to Norbert Kalmar and Michael Han for the work and everybody for
the participation.)

Regards,
Andor




On Fri, Mar 9, 2018 at 8:49 AM, Andor Molnar <an...@cloudera.com> wrote:

> Hi Shawn,
>
> Thanks for the feedback and thanks for everybody else too.
>
> The short term plan is to introduce Java 8 in next upcoming stable
> release, 3.5.
> Jumping 2 Java versions seems to be too much for me too.
>
> ZK master branch is going to be 3.6 release in which we can talk about
> upgrading to Java 9.
> What becomes later - I don't know - currently there's no plan for a 4.0
> release as far as I'm concerned.
>
> Regards,
> Andor
>
>
>
> On Fri, Mar 9, 2018 at 12:55 AM, Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 3/7/2018 1:21 PM, Jeff Widman wrote:
>> > +1 from me to using Java 8 or even going all the way to 9 for the 3.5
>> > release branch.
>>
>> I don't think it would be a good idea to require Java 9 at this time.
>> It's probably already an uphill battle for sysadmins to get approval to
>> jump ONE major version.  Getting approval to upgrade through TWO major
>> versions might prove to be very difficult for some.
>>
>> A year from now, after Java 8 goes end of support, might be the time to
>> have that discussion.
>>
>> I have no idea what kind of overall roadmap there is for ZK major
>> versions.  Maybe nobody has planned that far ahead.
>>
>> Ordinarily I would say that requiring a new major Java version should
>> happen in a major release, which would mean requiring Java 8 with the
>> 4.0 release and Java 9 with the 5.0 release.  But I know that ZK has a
>> very slow release cycle -- multiple months between *point* releases, and
>> far longer between minor releases.  I don't even know what kind of cycle
>> there is for major releases.  Maybe because of the slow release cycle,
>> waiting for 4.0 would just take too long.  So here's an alternate idea:
>> require Java 8 in 3.6.x and Java 9 in whatever minor or major release
>> comes after 3.6.
>>
>> For comparison purposes -- Lucene/Solr usually puts out a new minor
>> release every few weeks.  Point releases usually are VERY quick after a
>> minor release, and typically are only created for really massive bugs.
>>
>> Thanks,
>> Shawn
>>
>>
>

Re: Upgrade required Java version to 1.8 on 3.5+

[Andor Molnar <an...@cloudera.com>]

Hi Shawn,

Thanks for the feedback and thanks for everybody else too.

The short term plan is to introduce Java 8 in next upcoming stable release,
3.5.
Jumping 2 Java versions seems to be too much for me too.

ZK master branch is going to be 3.6 release in which we can talk about
upgrading to Java 9.
What becomes later - I don't know - currently there's no plan for a 4.0
release as far as I'm concerned.

Regards,
Andor



On Fri, Mar 9, 2018 at 12:55 AM, Shawn Heisey <ap...@elyograg.org> wrote:

> On 3/7/2018 1:21 PM, Jeff Widman wrote:
> > +1 from me to using Java 8 or even going all the way to 9 for the 3.5
> > release branch.
>
> I don't think it would be a good idea to require Java 9 at this time.
> It's probably already an uphill battle for sysadmins to get approval to
> jump ONE major version.  Getting approval to upgrade through TWO major
> versions might prove to be very difficult for some.
>
> A year from now, after Java 8 goes end of support, might be the time to
> have that discussion.
>
> I have no idea what kind of overall roadmap there is for ZK major
> versions.  Maybe nobody has planned that far ahead.
>
> Ordinarily I would say that requiring a new major Java version should
> happen in a major release, which would mean requiring Java 8 with the
> 4.0 release and Java 9 with the 5.0 release.  But I know that ZK has a
> very slow release cycle -- multiple months between *point* releases, and
> far longer between minor releases.  I don't even know what kind of cycle
> there is for major releases.  Maybe because of the slow release cycle,
> waiting for 4.0 would just take too long.  So here's an alternate idea:
> require Java 8 in 3.6.x and Java 9 in whatever minor or major release
> comes after 3.6.
>
> For comparison purposes -- Lucene/Solr usually puts out a new minor
> release every few weeks.  Point releases usually are VERY quick after a
> minor release, and typically are only created for really massive bugs.
>
> Thanks,
> Shawn
>
>

Re: Upgrade required Java version to 1.8 on 3.5+

[Shawn Heisey <ap...@elyograg.org>]

On 3/7/2018 1:21 PM, Jeff Widman wrote:
> +1 from me to using Java 8 or even going all the way to 9 for the 3.5
> release branch.

I don't think it would be a good idea to require Java 9 at this time. 
It's probably already an uphill battle for sysadmins to get approval to
jump ONE major version.  Getting approval to upgrade through TWO major
versions might prove to be very difficult for some.

A year from now, after Java 8 goes end of support, might be the time to
have that discussion.

I have no idea what kind of overall roadmap there is for ZK major
versions.  Maybe nobody has planned that far ahead.

Ordinarily I would say that requiring a new major Java version should
happen in a major release, which would mean requiring Java 8 with the
4.0 release and Java 9 with the 5.0 release.  But I know that ZK has a
very slow release cycle -- multiple months between *point* releases, and
far longer between minor releases.  I don't even know what kind of cycle
there is for major releases.  Maybe because of the slow release cycle,
waiting for 4.0 would just take too long.  So here's an alternate idea:
require Java 8 in 3.6.x and Java 9 in whatever minor or major release
comes after 3.6.

For comparison purposes -- Lucene/Solr usually puts out a new minor
release every few weeks.  Point releases usually are VERY quick after a
minor release, and typically are only created for really massive bugs.

Thanks,
Shawn

Re: Upgrade required Java version to 1.8 on 3.5+

[Jeff Widman <je...@jeffwidman.com>]

+1 from me to using Java 8 or even going all the way to 9 for the 3.5
release branch.

On Mar 7, 2018 8:17 AM, "Shawn Heisey" <ap...@elyograg.org> wrote:

> On 3/7/2018 4:04 AM, Andor Molnar wrote:
>
>> I've quickly checked some of the major components that are heavy Zk
>> clients:
>>
>> Hadoop/HDFS = 1.8 required
>> HBase = 1.8 required
>> Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
>> Hive = 1.8 required
>> Curator = 1.7 required (has 1.8-only async module to take advantage of
>> Java
>> lambdas)
>> Solr  = 1.8
>>
>> As always, your feedback is much appreciated.
>>
>
> I come from the Solr world.
>
> Lucene/Solr started requiring Java 7 with the release of 4.8.0, announced
> on 2014-04-28.
>
> Lucene/Solr started requiring Java 8 with the release of 6.0.0, announced
> on 2016-04-08.
>
> The general reaction each time one of these major changes was discussed
> seemed to be "oh, finally!  it's about time!"  I get the strong sense that
> Lucene committers really want to use the new language features, and feel
> limited when they can't. Historically, there have been a few changes
> committed that failed to compile when the officially supported minimum JDK
> version was used.  The authors probably should have noticed the problem,
> but sometimes don't because they're using updated toolchains.
>
> How do the committers on this project generally feel about needing to
> avoid using Java 8 features?  If they don't feel limited, there's probably
> no reason to update the requirement.  If however they feel that they could
> write better code with a refresh, then given general industry trends, it
> probably is time to consider updating the requirement.  Maybe you will want
> to accelerate plans for a 4.0 release, and update the requirement there.
>
> Another piece of information to think about:  Oracle isn't providing
> public support/bugfixes for Java 7 any more.  To get support, Oracle must
> be paid.  Java 8 is going to reach that same milestone in January 2019, so
> within the next year or so, we are going to begin seeing a lot of projects
> updating to a minimum of Java 9.
>
> Thanks,
> Shawn
>
>

Re: Upgrade required Java version to 1.8 on 3.5+

[Shawn Heisey <ap...@elyograg.org>]

On 3/7/2018 4:04 AM, Andor Molnar wrote:
> I've quickly checked some of the major components that are heavy Zk clients:
>
> Hadoop/HDFS = 1.8 required
> HBase = 1.8 required
> Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
> Hive = 1.8 required
> Curator = 1.7 required (has 1.8-only async module to take advantage of Java
> lambdas)
> Solr  = 1.8
>
> As always, your feedback is much appreciated.

I come from the Solr world.

Lucene/Solr started requiring Java 7 with the release of 4.8.0, 
announced on 2014-04-28.

Lucene/Solr started requiring Java 8 with the release of 6.0.0, 
announced on 2016-04-08.

The general reaction each time one of these major changes was discussed 
seemed to be "oh, finally!  it's about time!"  I get the strong sense 
that Lucene committers really want to use the new language features, and 
feel limited when they can't. Historically, there have been a few 
changes committed that failed to compile when the officially supported 
minimum JDK version was used.  The authors probably should have noticed 
the problem, but sometimes don't because they're using updated toolchains.

How do the committers on this project generally feel about needing to 
avoid using Java 8 features?  If they don't feel limited, there's 
probably no reason to update the requirement.  If however they feel that 
they could write better code with a refresh, then given general industry 
trends, it probably is time to consider updating the requirement.  Maybe 
you will want to accelerate plans for a 4.0 release, and update the 
requirement there.

Another piece of information to think about:  Oracle isn't providing 
public support/bugfixes for Java 7 any more.  To get support, Oracle 
must be paid.  Java 8 is going to reach that same milestone in January 
2019, so within the next year or so, we are going to begin seeing a lot 
of projects updating to a minimum of Java 9.

Thanks,
Shawn

Re: Upgrade required Java version to 1.8 on 3.5+

[Enrico Olivelli <eo...@gmail.com>]

Hi,
At BookKeeper we are supporting java 8 onwards and we are using 3.5
branch. (Speaking as BookKeeper PMC)

In my company we running all on java8 and we switching to java9, both
clients and servers

So good to see Zookeeper moving to java8

Enrico


Il mer 7 mar 2018, 12:04 Andor Molnar <an...@cloudera.com> ha scritto:

> Hi ZooKeeper users,
>
> There's an ongoing discussion on the dev list about upgrading the required
> Java version to 1.8 on trunk and 3.5 branches.
>
> We'd like to get some feedback from a bigger audience if anybody or any
> other component that is dependent on ZooKeeper has any concerns or
> objections against the change?
>
> I've quickly checked some of the major components that are heavy Zk
> clients:
>
> Hadoop/HDFS = 1.8 required
> HBase = 1.8 required
> Kafka = 1.7 required (has some 1.8 and 1.9 bindings)
> Hive = 1.8 required
> Curator = 1.7 required (has 1.8-only async module to take advantage of Java
> lambdas)
> Solr  = 1.8
>
> As always, your feedback is much appreciated.
>
> Thanks,
> Andor
>
-- 


-- Enrico Olivelli