Are we embracing Java 8?

[Mingliang Liu <li...@gmail.com>]

Hi,

I filed PHOENIX-5855 <https://issues.apache.org/jira/browse/PHOENIX-5855> to
make the code more Java 8. This may apply to master branch only and Istvan
Toth expressed concern about backporting conflicts.

I guess this is the trade-off between embracing newer Java platform (Java 7
is EOL and will not be supported next year) and the effort of resolving
conflict if any when backporting.

The options are:

   1. get stuck in Java 7 for both master and all old branches. We are
   basically on this approach as I see Java 8 is used very sparingly in master
   branch
   2. use Java 8 in master branch extensively and take care of minor
   conflicts if any for all 4.x branches. Patch author can provide separate
   patch if conflict is major, or make changes with less conflict.
   3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches will
   still need some manual fix as above.

I think it is the right time for option 2 or 3. Thoughts?

Thanks,
-- 
L

Re: Are we embracing Java 8?

[Istvan Toth <st...@cloudera.com.INVALID>]

We don't have nightly builds, we have post-commit jobs instead, but they
mostly serve the same purpose.
The post-commit job is simpler, and does not require Yetus knowledge to
modify.
It is defined by */Jenkinsfile*, which uses /
*dev/docker/Dockerfile.multibranch *.

You need check if the Yetus image already has Java 7, add it if it doesn't,
add itt in Dockerfile.multibranch.
Then you just need to make sure that maven uses that one for the build.


On Tue, Oct 27, 2020 at 11:28 AM Viraj Jasani <vj...@apache.org> wrote:

> Thanks Istvan for all the pointers!
> Do you think switching 4.x nightly (in multi branch) to use JDK 7 only
> might be less time consuming to configure? That might also be quite helpful
> at this point given that there is no plan to commit any change to 4.x which
> is not compatible with Java 7.
> Hence, if not precommit Jira/github builds, then nightly can catch
> incompatible changes.
>
>
> On Tue, 27 Oct 2020 at 10:44 AM, Istvan Toth <st...@cloudera.com.invalid>
> wrote:
>
> > Some thoughts on Yetus:
> >
> > The only limit on what we can do is the load that we put on the ASF
> > infrastructure, but that is a rather hard limit.
> > The Yetus precommit check does not by default run the unit tests, but I
> > hacked the personality to add the unit tests to it to preserve the old
> > behaviour.
> >
> > We have at least two dimensions that we can extend the testing to, one is
> > the HBase version used, the other is the JDK version.
> >
> > The Hbase Yetus scripts and personality already has solutions to these
> > issues, but I have cut some corners when adopting the script to Yetus,
> > partly to mimic the old precommit behaviour and partly to simplify
> bringing
> > up the tests.
> >
> > If we want to go in this direction, then we need to undo most of the
> > simplifications that I've done while porting the HBase stuff to Phoenix:
> > * Decouple running the IT suite from the standard Yetus precommit job to
> > keep resource use in check
> > * Restore the JDK multiversion and multi-Hadoop (in our case multi-HBase)
> > functionality in the Yetus personality and scripts.
> > * Use the intended Yetus mechanisms to run the IT suite and replace the
> > current post-commit scripts with Yetus-based nightlies.
> >
> > I do not expect to have the time to work on the above until all of the
> 5.1
> > releases are done, and the related @dayjob tasks wind down, but would
> > gladly give help / pointers to anyone willing to tackle these issues.
> >
> >
> > On Mon, Oct 26, 2020 at 8:17 PM Viraj Jasani <vj...@apache.org> wrote:
> >
> > > Based on a recent incident, I thought of bumping this thread.
> > >
> > > I agree with Chinmay on using JDK7 for our 4.x builds. Now with
> > > Yetus support (after last discussion on this thread), maybe we
> > > can consider supporting MULTIJDK environment (JDK7+JDK8) too
> > > with parallel execution of precommit checks stage?
> > >
> > >
> > > On 2020/05/11 22:41:51, Chinmay Kulkarni <ch...@gmail.com>
> > > wrote:
> > > > Sorry to slightly digress, but based on these discussions, shouldn't
> we
> > > be
> > > > setting JAVA_HOME to point to JDK 7 in all our builds? Especially
> based
> > > on
> > > > Andrew's comment above:
> > > > "
> > > >
> > > >
> > > > *Java 7 is not forwards compatible with Java 8, especially with
> respect
> > > > toJRE internals. What that means is if you compile something with
> Java
> > > > 8,even if you are not using Java 8 language features, you won't be
> able
> > > > torun it on a Java 7 runtime.*"
> > > >
> > > > Our 4.x build
> > > > <
> > >
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> > > >
> > > > is configured with java 1.8:
> > > > [image: 4.x.png]
> > > > In our master build
> > > > <
> > >
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure
> > > >,
> > > > we don't even specify JAVA_HOME, so essentially it picks up the
> latest
> > > > version. Precommit gets JAVA_HOME set from
> $PHOENIX/dev/jenkensEnv.sh.
> > > >
> > > > There have been issues where master builds failed because they used
> JDK
> > > 11 (
> > > >
> > >
> >
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull
> > > ),
> > > > search for "JAVA VERSION" in the log file. The same build does not
> fail
> > > if
> > > > run with JDK 8.
> > > >
> > > > Also, doesn't this mean we are already compiling with Java 8 (at
> least
> > in
> > > > the 4.x branches) or am I missing something?
> > > >
> > > > <
> > >
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> > > >
> > > >
> > > > On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <
> > ankitsinghal59@gmail.com>
> > > > wrote:
> > > >
> > > > > Just linking a discussion we had one and a half years back on the
> > same
> > > [1],
> > > > > considering nothing has changed since then because Java 7 was EOLed
> > in
> > > July
> > > > > 2015
> > > > > and Phoenix 5.0 was also out, it majorly comes to the point of the
> > > > > inconvenience of working
> > > > > on old code style and extra efforts required to create patches for
> > each
> > > > > branch.
> > > > >
> > > > > Let's say if we decide to upgrade to Java8(Option 3), don't we
> > require
> > > the
> > > > > following changes?
> > > > >
> > > > > * Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As
> > > upgrading
> > > > > 4.x branches
> > > > > to Java8 breaks the compatibility with HBase and Java runtime, we
> > need
> > > to
> > > > > ensure that
> > > > > we adhere to dependency compatibility between the minor releases as
> > it
> > > is
> > > > > expected that
> > > > > Phoenix minor upgrade should be just a server jar drop and a
> restart
> > > (even
> > > > > though
> > > > > we don't explicit covers Java runtime in our backward compatibility
> > > [2] as
> > > > > HBase does[3]
> > > > > but people are used to it now)
> > > > >
> > > > > * Release Notes and convenience libraries:- Though we would say
> that
> > > it is
> > > > > compatible with
> > > > > HBase version 1.x but require a Java8, so we need to be explicit
> with
> > > our
> > > > > convenience libraries
> > > > > as well , like append "jdk8" to a name or something similar
> > > > > (phoenix-server-HBase-1.x-jdk8.jar).
> > > > > And also provide clarity on the version upgrade
> > > > >
> > > > > * Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said
> to
> > > be
> > > > > binary compatible
> > > > > and are expected to be fine in Java8 runtime but it has been called
> > out
> > > > > there are rare instances
> > > > > which can cause issues due to some incompatibilities between JRE
> and
> > > > > JDK[4]. (As Andrew also
> > > > > called out and might have observed the same)
> > > > >
> > > > >
> > > > > Though I agreed with Istvan that creating multiple patches and
> > dealing
> > > with
> > > > > change in code style every time
> > > > > we switch branches has put additional load on the contributor but
> > > IMHO, we
> > > > > should wait for
> > > > > HBase-1.x to upgrade Java before we do it to avoid the some of the
> > > issues
> > > > > listed above related to Option 3.
> > > > >
> > > > > Option2 would be preferred at the time when we decide on whether we
> > > want to
> > > > > diverge from feature
> > > > > parity in our major releases and we do only limited fixes for 4.x
> > > branch.
> > > > > So basically I'm also in favor of Option 1 (continuing Java 7 for
> > > HBase-1.x
> > > > > and code style as much possible for 5.x).
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > >
> >
> https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
> > > > > [2]http://phoenix.apache.org/upgrading.html
> > > > > [3] https://hbase.apache.org/book.html#hbase.versioning
> > > > > [4]
> > > > >
> > > > >
> > >
> >
> https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387
> > > > >
> > > > > Regards,
> > > > > Ankit Singhal
> > > > >
> > > >
> > > >
> > > > --
> > > > Chinmay Kulkarni
> > > >
> > >
> >
> >
> > --
> > *István Tóth* | Staff Software Engineer
> > stoty@cloudera.com <https://www.cloudera.com>
> > [image: Cloudera] <https://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>
> > <https://www.cloudera.com/>
> > ------------------------------
> >
>


-- 
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://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>
<https://www.cloudera.com/>
------------------------------

Re: Are we embracing Java 8?

[Viraj Jasani <vj...@apache.org>]

Thanks Istvan for all the pointers!
Do you think switching 4.x nightly (in multi branch) to use JDK 7 only
might be less time consuming to configure? That might also be quite helpful
at this point given that there is no plan to commit any change to 4.x which
is not compatible with Java 7.
Hence, if not precommit Jira/github builds, then nightly can catch
incompatible changes.


On Tue, 27 Oct 2020 at 10:44 AM, Istvan Toth <st...@cloudera.com.invalid>
wrote:

> Some thoughts on Yetus:
>
> The only limit on what we can do is the load that we put on the ASF
> infrastructure, but that is a rather hard limit.
> The Yetus precommit check does not by default run the unit tests, but I
> hacked the personality to add the unit tests to it to preserve the old
> behaviour.
>
> We have at least two dimensions that we can extend the testing to, one is
> the HBase version used, the other is the JDK version.
>
> The Hbase Yetus scripts and personality already has solutions to these
> issues, but I have cut some corners when adopting the script to Yetus,
> partly to mimic the old precommit behaviour and partly to simplify bringing
> up the tests.
>
> If we want to go in this direction, then we need to undo most of the
> simplifications that I've done while porting the HBase stuff to Phoenix:
> * Decouple running the IT suite from the standard Yetus precommit job to
> keep resource use in check
> * Restore the JDK multiversion and multi-Hadoop (in our case multi-HBase)
> functionality in the Yetus personality and scripts.
> * Use the intended Yetus mechanisms to run the IT suite and replace the
> current post-commit scripts with Yetus-based nightlies.
>
> I do not expect to have the time to work on the above until all of the 5.1
> releases are done, and the related @dayjob tasks wind down, but would
> gladly give help / pointers to anyone willing to tackle these issues.
>
>
> On Mon, Oct 26, 2020 at 8:17 PM Viraj Jasani <vj...@apache.org> wrote:
>
> > Based on a recent incident, I thought of bumping this thread.
> >
> > I agree with Chinmay on using JDK7 for our 4.x builds. Now with
> > Yetus support (after last discussion on this thread), maybe we
> > can consider supporting MULTIJDK environment (JDK7+JDK8) too
> > with parallel execution of precommit checks stage?
> >
> >
> > On 2020/05/11 22:41:51, Chinmay Kulkarni <ch...@gmail.com>
> > wrote:
> > > Sorry to slightly digress, but based on these discussions, shouldn't we
> > be
> > > setting JAVA_HOME to point to JDK 7 in all our builds? Especially based
> > on
> > > Andrew's comment above:
> > > "
> > >
> > >
> > > *Java 7 is not forwards compatible with Java 8, especially with respect
> > > toJRE internals. What that means is if you compile something with Java
> > > 8,even if you are not using Java 8 language features, you won't be able
> > > torun it on a Java 7 runtime.*"
> > >
> > > Our 4.x build
> > > <
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> > >
> > > is configured with java 1.8:
> > > [image: 4.x.png]
> > > In our master build
> > > <
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure
> > >,
> > > we don't even specify JAVA_HOME, so essentially it picks up the latest
> > > version. Precommit gets JAVA_HOME set from $PHOENIX/dev/jenkensEnv.sh.
> > >
> > > There have been issues where master builds failed because they used JDK
> > 11 (
> > >
> >
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull
> > ),
> > > search for "JAVA VERSION" in the log file. The same build does not fail
> > if
> > > run with JDK 8.
> > >
> > > Also, doesn't this mean we are already compiling with Java 8 (at least
> in
> > > the 4.x branches) or am I missing something?
> > >
> > > <
> >
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> > >
> > >
> > > On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <
> ankitsinghal59@gmail.com>
> > > wrote:
> > >
> > > > Just linking a discussion we had one and a half years back on the
> same
> > [1],
> > > > considering nothing has changed since then because Java 7 was EOLed
> in
> > July
> > > > 2015
> > > > and Phoenix 5.0 was also out, it majorly comes to the point of the
> > > > inconvenience of working
> > > > on old code style and extra efforts required to create patches for
> each
> > > > branch.
> > > >
> > > > Let's say if we decide to upgrade to Java8(Option 3), don't we
> require
> > the
> > > > following changes?
> > > >
> > > > * Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As
> > upgrading
> > > > 4.x branches
> > > > to Java8 breaks the compatibility with HBase and Java runtime, we
> need
> > to
> > > > ensure that
> > > > we adhere to dependency compatibility between the minor releases as
> it
> > is
> > > > expected that
> > > > Phoenix minor upgrade should be just a server jar drop and a restart
> > (even
> > > > though
> > > > we don't explicit covers Java runtime in our backward compatibility
> > [2] as
> > > > HBase does[3]
> > > > but people are used to it now)
> > > >
> > > > * Release Notes and convenience libraries:- Though we would say that
> > it is
> > > > compatible with
> > > > HBase version 1.x but require a Java8, so we need to be explicit with
> > our
> > > > convenience libraries
> > > > as well , like append "jdk8" to a name or something similar
> > > > (phoenix-server-HBase-1.x-jdk8.jar).
> > > > And also provide clarity on the version upgrade
> > > >
> > > > * Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to
> > be
> > > > binary compatible
> > > > and are expected to be fine in Java8 runtime but it has been called
> out
> > > > there are rare instances
> > > > which can cause issues due to some incompatibilities between JRE and
> > > > JDK[4]. (As Andrew also
> > > > called out and might have observed the same)
> > > >
> > > >
> > > > Though I agreed with Istvan that creating multiple patches and
> dealing
> > with
> > > > change in code style every time
> > > > we switch branches has put additional load on the contributor but
> > IMHO, we
> > > > should wait for
> > > > HBase-1.x to upgrade Java before we do it to avoid the some of the
> > issues
> > > > listed above related to Option 3.
> > > >
> > > > Option2 would be preferred at the time when we decide on whether we
> > want to
> > > > diverge from feature
> > > > parity in our major releases and we do only limited fixes for 4.x
> > branch.
> > > > So basically I'm also in favor of Option 1 (continuing Java 7 for
> > HBase-1.x
> > > > and code style as much possible for 5.x).
> > > >
> > > > [1]
> > > >
> > > >
> >
> https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
> > > > [2]http://phoenix.apache.org/upgrading.html
> > > > [3] https://hbase.apache.org/book.html#hbase.versioning
> > > > [4]
> > > >
> > > >
> >
> https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387
> > > >
> > > > Regards,
> > > > Ankit Singhal
> > > >
> > >
> > >
> > > --
> > > Chinmay Kulkarni
> > >
> >
>
>
> --
> *István Tóth* | Staff Software Engineer
> stoty@cloudera.com <https://www.cloudera.com>
> [image: Cloudera] <https://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>
> <https://www.cloudera.com/>
> ------------------------------
>

Re: Are we embracing Java 8?

[Istvan Toth <st...@cloudera.com.INVALID>]

Some thoughts on Yetus:

The only limit on what we can do is the load that we put on the ASF
infrastructure, but that is a rather hard limit.
The Yetus precommit check does not by default run the unit tests, but I
hacked the personality to add the unit tests to it to preserve the old
behaviour.

We have at least two dimensions that we can extend the testing to, one is
the HBase version used, the other is the JDK version.

The Hbase Yetus scripts and personality already has solutions to these
issues, but I have cut some corners when adopting the script to Yetus,
partly to mimic the old precommit behaviour and partly to simplify bringing
up the tests.

If we want to go in this direction, then we need to undo most of the
simplifications that I've done while porting the HBase stuff to Phoenix:
* Decouple running the IT suite from the standard Yetus precommit job to
keep resource use in check
* Restore the JDK multiversion and multi-Hadoop (in our case multi-HBase)
functionality in the Yetus personality and scripts.
* Use the intended Yetus mechanisms to run the IT suite and replace the
current post-commit scripts with Yetus-based nightlies.

I do not expect to have the time to work on the above until all of the 5.1
releases are done, and the related @dayjob tasks wind down, but would
gladly give help / pointers to anyone willing to tackle these issues.


On Mon, Oct 26, 2020 at 8:17 PM Viraj Jasani <vj...@apache.org> wrote:

> Based on a recent incident, I thought of bumping this thread.
>
> I agree with Chinmay on using JDK7 for our 4.x builds. Now with
> Yetus support (after last discussion on this thread), maybe we
> can consider supporting MULTIJDK environment (JDK7+JDK8) too
> with parallel execution of precommit checks stage?
>
>
> On 2020/05/11 22:41:51, Chinmay Kulkarni <ch...@gmail.com>
> wrote:
> > Sorry to slightly digress, but based on these discussions, shouldn't we
> be
> > setting JAVA_HOME to point to JDK 7 in all our builds? Especially based
> on
> > Andrew's comment above:
> > "
> >
> >
> > *Java 7 is not forwards compatible with Java 8, especially with respect
> > toJRE internals. What that means is if you compile something with Java
> > 8,even if you are not using Java 8 language features, you won't be able
> > torun it on a Java 7 runtime.*"
> >
> > Our 4.x build
> > <
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> >
> > is configured with java 1.8:
> > [image: 4.x.png]
> > In our master build
> > <
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure
> >,
> > we don't even specify JAVA_HOME, so essentially it picks up the latest
> > version. Precommit gets JAVA_HOME set from $PHOENIX/dev/jenkensEnv.sh.
> >
> > There have been issues where master builds failed because they used JDK
> 11 (
> >
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull
> ),
> > search for "JAVA VERSION" in the log file. The same build does not fail
> if
> > run with JDK 8.
> >
> > Also, doesn't this mean we are already compiling with Java 8 (at least in
> > the 4.x branches) or am I missing something?
> >
> > <
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure
> >
> >
> > On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <an...@gmail.com>
> > wrote:
> >
> > > Just linking a discussion we had one and a half years back on the same
> [1],
> > > considering nothing has changed since then because Java 7 was EOLed in
> July
> > > 2015
> > > and Phoenix 5.0 was also out, it majorly comes to the point of the
> > > inconvenience of working
> > > on old code style and extra efforts required to create patches for each
> > > branch.
> > >
> > > Let's say if we decide to upgrade to Java8(Option 3), don't we require
> the
> > > following changes?
> > >
> > > * Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As
> upgrading
> > > 4.x branches
> > > to Java8 breaks the compatibility with HBase and Java runtime, we need
> to
> > > ensure that
> > > we adhere to dependency compatibility between the minor releases as it
> is
> > > expected that
> > > Phoenix minor upgrade should be just a server jar drop and a restart
> (even
> > > though
> > > we don't explicit covers Java runtime in our backward compatibility
> [2] as
> > > HBase does[3]
> > > but people are used to it now)
> > >
> > > * Release Notes and convenience libraries:- Though we would say that
> it is
> > > compatible with
> > > HBase version 1.x but require a Java8, so we need to be explicit with
> our
> > > convenience libraries
> > > as well , like append "jdk8" to a name or something similar
> > > (phoenix-server-HBase-1.x-jdk8.jar).
> > > And also provide clarity on the version upgrade
> > >
> > > * Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to
> be
> > > binary compatible
> > > and are expected to be fine in Java8 runtime but it has been called out
> > > there are rare instances
> > > which can cause issues due to some incompatibilities between JRE and
> > > JDK[4]. (As Andrew also
> > > called out and might have observed the same)
> > >
> > >
> > > Though I agreed with Istvan that creating multiple patches and dealing
> with
> > > change in code style every time
> > > we switch branches has put additional load on the contributor but
> IMHO, we
> > > should wait for
> > > HBase-1.x to upgrade Java before we do it to avoid the some of the
> issues
> > > listed above related to Option 3.
> > >
> > > Option2 would be preferred at the time when we decide on whether we
> want to
> > > diverge from feature
> > > parity in our major releases and we do only limited fixes for 4.x
> branch.
> > > So basically I'm also in favor of Option 1 (continuing Java 7 for
> HBase-1.x
> > > and code style as much possible for 5.x).
> > >
> > > [1]
> > >
> > >
> https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
> > > [2]http://phoenix.apache.org/upgrading.html
> > > [3] https://hbase.apache.org/book.html#hbase.versioning
> > > [4]
> > >
> > >
> https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387
> > >
> > > Regards,
> > > Ankit Singhal
> > >
> >
> >
> > --
> > Chinmay Kulkarni
> >
>


-- 
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://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>
<https://www.cloudera.com/>
------------------------------

Re: Are we embracing Java 8?

[Viraj Jasani <vj...@apache.org>]

Based on a recent incident, I thought of bumping this thread.

I agree with Chinmay on using JDK7 for our 4.x builds. Now with 
Yetus support (after last discussion on this thread), maybe we
can consider supporting MULTIJDK environment (JDK7+JDK8) too 
with parallel execution of precommit checks stage?


On 2020/05/11 22:41:51, Chinmay Kulkarni <ch...@gmail.com> wrote: 
> Sorry to slightly digress, but based on these discussions, shouldn't we be
> setting JAVA_HOME to point to JDK 7 in all our builds? Especially based on
> Andrew's comment above:
> "
> 
> 
> *Java 7 is not forwards compatible with Java 8, especially with respect
> toJRE internals. What that means is if you compile something with Java
> 8,even if you are not using Java 8 language features, you won't be able
> torun it on a Java 7 runtime.*"
> 
> Our 4.x build
> <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure>
> is configured with java 1.8:
> [image: 4.x.png]
> In our master build
> <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure>,
> we don't even specify JAVA_HOME, so essentially it picks up the latest
> version. Precommit gets JAVA_HOME set from $PHOENIX/dev/jenkensEnv.sh.
> 
> There have been issues where master builds failed because they used JDK 11 (
> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull),
> search for "JAVA VERSION" in the log file. The same build does not fail if
> run with JDK 8.
> 
> Also, doesn't this mean we are already compiling with Java 8 (at least in
> the 4.x branches) or am I missing something?
> 
> <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure>
> 
> On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <an...@gmail.com>
> wrote:
> 
> > Just linking a discussion we had one and a half years back on the same [1],
> > considering nothing has changed since then because Java 7 was EOLed in July
> > 2015
> > and Phoenix 5.0 was also out, it majorly comes to the point of the
> > inconvenience of working
> > on old code style and extra efforts required to create patches for each
> > branch.
> >
> > Let's say if we decide to upgrade to Java8(Option 3), don't we require the
> > following changes?
> >
> > * Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As upgrading
> > 4.x branches
> > to Java8 breaks the compatibility with HBase and Java runtime, we need to
> > ensure that
> > we adhere to dependency compatibility between the minor releases as it is
> > expected that
> > Phoenix minor upgrade should be just a server jar drop and a restart (even
> > though
> > we don't explicit covers Java runtime in our backward compatibility [2] as
> > HBase does[3]
> > but people are used to it now)
> >
> > * Release Notes and convenience libraries:- Though we would say that it is
> > compatible with
> > HBase version 1.x but require a Java8, so we need to be explicit with our
> > convenience libraries
> > as well , like append "jdk8" to a name or something similar
> > (phoenix-server-HBase-1.x-jdk8.jar).
> > And also provide clarity on the version upgrade
> >
> > * Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to be
> > binary compatible
> > and are expected to be fine in Java8 runtime but it has been called out
> > there are rare instances
> > which can cause issues due to some incompatibilities between JRE and
> > JDK[4]. (As Andrew also
> > called out and might have observed the same)
> >
> >
> > Though I agreed with Istvan that creating multiple patches and dealing with
> > change in code style every time
> > we switch branches has put additional load on the contributor but IMHO, we
> > should wait for
> > HBase-1.x to upgrade Java before we do it to avoid the some of the issues
> > listed above related to Option 3.
> >
> > Option2 would be preferred at the time when we decide on whether we want to
> > diverge from feature
> > parity in our major releases and we do only limited fixes for 4.x branch.
> > So basically I'm also in favor of Option 1 (continuing Java 7 for HBase-1.x
> > and code style as much possible for 5.x).
> >
> > [1]
> >
> > https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
> > [2]http://phoenix.apache.org/upgrading.html
> > [3] https://hbase.apache.org/book.html#hbase.versioning
> > [4]
> >
> > https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387
> >
> > Regards,
> > Ankit Singhal
> >
> 
> 
> -- 
> Chinmay Kulkarni
> 

Re: Are we embracing Java 8?

[Chinmay Kulkarni <ch...@gmail.com>]

Sorry to slightly digress, but based on these discussions, shouldn't we be
setting JAVA_HOME to point to JDK 7 in all our builds? Especially based on
Andrew's comment above:
"


*Java 7 is not forwards compatible with Java 8, especially with respect
toJRE internals. What that means is if you compile something with Java
8,even if you are not using Java 8 language features, you won't be able
torun it on a Java 7 runtime.*"

Our 4.x build
<https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure>
is configured with java 1.8:
[image: 4.x.png]
In our master build
<https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure>,
we don't even specify JAVA_HOME, so essentially it picks up the latest
version. Precommit gets JAVA_HOME set from $PHOENIX/dev/jenkensEnv.sh.

There have been issues where master builds failed because they used JDK 11 (
https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull),
search for "JAVA VERSION" in the log file. The same build does not fail if
run with JDK 8.

Also, doesn't this mean we are already compiling with Java 8 (at least in
the 4.x branches) or am I missing something?

<https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure>

On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <an...@gmail.com>
wrote:

> Just linking a discussion we had one and a half years back on the same [1],
> considering nothing has changed since then because Java 7 was EOLed in July
> 2015
> and Phoenix 5.0 was also out, it majorly comes to the point of the
> inconvenience of working
> on old code style and extra efforts required to create patches for each
> branch.
>
> Let's say if we decide to upgrade to Java8(Option 3), don't we require the
> following changes?
>
> * Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As upgrading
> 4.x branches
> to Java8 breaks the compatibility with HBase and Java runtime, we need to
> ensure that
> we adhere to dependency compatibility between the minor releases as it is
> expected that
> Phoenix minor upgrade should be just a server jar drop and a restart (even
> though
> we don't explicit covers Java runtime in our backward compatibility [2] as
> HBase does[3]
> but people are used to it now)
>
> * Release Notes and convenience libraries:- Though we would say that it is
> compatible with
> HBase version 1.x but require a Java8, so we need to be explicit with our
> convenience libraries
> as well , like append "jdk8" to a name or something similar
> (phoenix-server-HBase-1.x-jdk8.jar).
> And also provide clarity on the version upgrade
>
> * Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to be
> binary compatible
> and are expected to be fine in Java8 runtime but it has been called out
> there are rare instances
> which can cause issues due to some incompatibilities between JRE and
> JDK[4]. (As Andrew also
> called out and might have observed the same)
>
>
> Though I agreed with Istvan that creating multiple patches and dealing with
> change in code style every time
> we switch branches has put additional load on the contributor but IMHO, we
> should wait for
> HBase-1.x to upgrade Java before we do it to avoid the some of the issues
> listed above related to Option 3.
>
> Option2 would be preferred at the time when we decide on whether we want to
> diverge from feature
> parity in our major releases and we do only limited fixes for 4.x branch.
> So basically I'm also in favor of Option 1 (continuing Java 7 for HBase-1.x
> and code style as much possible for 5.x).
>
> [1]
>
> https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
> [2]http://phoenix.apache.org/upgrading.html
> [3] https://hbase.apache.org/book.html#hbase.versioning
> [4]
>
> https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387
>
> Regards,
> Ankit Singhal
>


-- 
Chinmay Kulkarni

Re: Are we embracing Java 8?

[Ankit Singhal <an...@gmail.com>]

Just linking a discussion we had one and a half years back on the same [1],
considering nothing has changed since then because Java 7 was EOLed in July
2015
and Phoenix 5.0 was also out, it majorly comes to the point of the
inconvenience of working
on old code style and extra efforts required to create patches for each
branch.

Let's say if we decide to upgrade to Java8(Option 3), don't we require the
following changes?

* Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As upgrading
4.x branches
to Java8 breaks the compatibility with HBase and Java runtime, we need to
ensure that
we adhere to dependency compatibility between the minor releases as it is
expected that
Phoenix minor upgrade should be just a server jar drop and a restart (even
though
we don't explicit covers Java runtime in our backward compatibility [2] as
HBase does[3]
but people are used to it now)

* Release Notes and convenience libraries:- Though we would say that it is
compatible with
HBase version 1.x but require a Java8, so we need to be explicit with our
convenience libraries
as well , like append "jdk8" to a name or something similar
(phoenix-server-HBase-1.x-jdk8.jar).
And also provide clarity on the version upgrade

* Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to be
binary compatible
and are expected to be fine in Java8 runtime but it has been called out
there are rare instances
which can cause issues due to some incompatibilities between JRE and
JDK[4]. (As Andrew also
called out and might have observed the same)


Though I agreed with Istvan that creating multiple patches and dealing with
change in code style every time
we switch branches has put additional load on the contributor but IMHO, we
should wait for
HBase-1.x to upgrade Java before we do it to avoid the some of the issues
listed above related to Option 3.

Option2 would be preferred at the time when we decide on whether we want to
diverge from feature
parity in our major releases and we do only limited fixes for 4.x branch.
So basically I'm also in favor of Option 1 (continuing Java 7 for HBase-1.x
and code style as much possible for 5.x).

[1]
https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E
[2]http://phoenix.apache.org/upgrading.html
[3] https://hbase.apache.org/book.html#hbase.versioning
[4]
https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387

Regards,
Ankit Singhal

Re: Are we embracing Java 8?

[Andrew Purtell <an...@gmail.com>]

Yes, a real cluster, ideally a real application. With some stress. Some scale too if it can be managed. 

> On Apr 22, 2020, at 6:10 AM, Istvan Toth <st...@apache.org> wrote:
> 
> Agreed, making this change only makes sense if we bump the source version,
> and also compile Java 8 bytecode, which precludes Java7 support.
> Cross-compiling to Java 7 would defeat the whole point of bumping the Java
> version.
> 
> Re the test issue:
> 
> I am pretty sure that If we bump the Java version in the 4.x POM, then run
> the standard test suite, it will test the very java compiler/runtime
> combination that you are referring to.
> Java 8 will be used to compile the Phoenix classes, The HBase and Hadoop
> artifacts that maven pulls in will be Compiled with 1.7, and the Java
> Runtime that runs all of this will be Java 8.
> 
> What testing do you have in mind that would be more thorough than that ?
> We can run the test suite on a real HBase 1.3 cluster as well (most of it),
> but since we have but one test suite, the only difference would be that
> HBase and Java run in different JVMs.
> (Of course, it would be useful, and probably worth doing, but it would be
> fundamentally the same Java/JVM combination)
> 
> regards
> Istvan
> 
>> On Wed, Apr 22, 2020 at 7:29 AM Andrew Purtell <an...@gmail.com>
>> wrote:
>> 
>> Yes, what I was trying to say is even if you don't adopt 8 language
>> features and specify a source level of 7 when compiling the binaries, there
>> will be other runtime issues. And so sure there's no reason to hold back on
>> source level changes. The runtime compatibility story will change
>> overnight.
>> 
>> Regarding testing... Unless you think that someone won't download a HBase
>> binary release (1.x will be compiled with 7), and then a future Phoenix
>> binary release (compiled with 8), and then try to combine them, you should
>> probably test that combination. (Smile.)
>> 
>> 
>>>> On Apr 21, 2020, at 9:44 PM, Istvan Toth <st...@apache.org> wrote:
>>> 
>>> Hi!
>>> 
>>> Actually, the convenience binaries would be the least of a (hypothetical)
>>> Java7 user's problem.
>>> The whole point of moving 4.x to Java8 would be to enable the usage of
>>> Java8 features in the project,
>>> so almost immediately the 4.x branch wouldn't even compile on 4.x .
>>> 
>>> I would imagine that any installation still stuck on Java7 would be a
>>> thoroughly legacy system where updating Phoenix is not a priority.
>>> 
>>> I agree with the importance of having to thoroughly and prominently
>>> document such a change.
>>> 
>>> I am not sure that additional testing would be needed to test the
>> HBase1.x
>>> compiled with Java7 case,
>>> AFAICT our IT suite would test exactly that case, as the HBase1.x
>> artifacts
>>> in Maven that the tests pull in are compiled on Java7.
>>> 
>>> Miangliang is certainly not the only one who wants to use Java8 features.
>>> This is a limitation that the old hands may be used to, but
>>> is a pain point for bright-eyed new contributors. I know I've had to ask
>> a
>>> new dev to rewrite Java8 specific code multiple times,
>>> not to mention having to rewrite my code on backport when I didn't
>> realize
>>> that the feature I used was Java8 specific.
>>> 
>>> I can see these three outcomes:
>>> 
>>> a. Switch 4.x to Java 8 now, and deal with the Java8->Java7 porting
>> issues
>>> on backporting to 4.15.x
>>> b. Switch 4.x to Java 8 on the release on 4.16, thereby saving the
>>> backporting issues on 4.15.x
>>> c. Postpone switching to Java8 until HBase 1.x goes out of support.
>>> 
>>> I know that no-one wants to commit to release dates, but do we even plan
>> to
>>> have a 4.16 release soon-ish ?
>>> Based on historical release cadence, it could be anytime from next month
>> to
>>> next year.
>>> 
>>> Having more or less established that no-one who is active on the dev list
>>> cares about Java 7 for his/her own use,
>>> how should we go forward with this ?
>>> 
>>> Is this something that we should have a formal vote on ?
>>> 
>>> Disclaimer: my employer doesn't support recent Phoenix 4.x versions, so
>> my
>>> opinions may be tinted by that.
>>> 
>>> regards
>>> Istvan
>>> 
>>>> On Wed, Apr 22, 2020 at 3:50 AM Andrew Purtell <ap...@apache.org>
>> wrote:
>>>> 
>>>> Just to be super clear:
>>>> 
>>>>> Compile the code with Java 8, then if someone tries to install the
>>>> resulting binaries into a HBase convenience binary release 1.x, which
>> will
>>>> have been compiled with Java 7, the regionserver will abort.
>>>> 
>>>> ... if the code is running on Java 7.
>>>> 
>>>> I don't know if anyone is actually still running Java 7 anywhere, and
>>>> wanting to use HBase and Phoenix on that runtime, but it's possible. We
>>>> haven't tried to move up minimum Java version on HBase 1.x because it's
>>>> impossible to know who is using it where, and originally it was released
>>>> for/on 7. You can decide it is unlikely enough to move forward, but
>> should
>>>> at least document the implications somewhere on the release page.
>>>> 
>>>> I'm pretty sure HBase compiled with 7 and Phoenix compiled with 8,
>> running
>>>> on 8 or later, will be stable, but this configuration obviously should
>> be
>>>> rigorously tested if you plan to move up.
>>>> 
>>>> </eom>
>>>> 
>>>> 
>>>> On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell <ap...@apache.org>
>>>> wrote:
>>>> 
>>>>> The main problem you will face is the convenience binaries.
>>>>> 
>>>>> If you are planning to move to Java 8, for 4.x branches, then you will
>> no
>>>>> longer be able to make binary convenience releases compatible with any
>>>>> HBase 1.x convenience binary, even if you don't adopt any Java 8
>> language
>>>>> features. Compile the code with Java 8, then if someone tries to
>> install
>>>>> the resulting binaries into a HBase convenience binary release 1.x,
>> which
>>>>> will have been compiled with Java 7, the regionserver will abort.
>>>>> 
>>>>> Java 8 is backwards compatible with Java 7. That is, if you compile
>> with
>>>>> Java 7 but run on a Java 8 runtime, all is good, even linkage in the
>> JRE.
>>>>> 
>>>>> Java 7 is not forwards compatible with Java 8, especially with respect
>> to
>>>>> JRE internals. What that means is if you compile something with Java 8,
>>>>> even if you are not using Java 8 language features, you won't be able
>> to
>>>>> run it on a Java 7 runtime. Notably, there are linkage errors in the
>>>>> j.u.concurrent package, which as you know both Phoenix and HBase use
>>>>> extensively. I suppose this doesn't matter if you are adopting Java 8
>>>>> language features anyway.
>>>>> 
>>>>> Seems a big deal to move to source only releases for 4.x, but that is
>> an
>>>>> option.
>>>>> 
>>>>> 
>>>>>> On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> Given that in a few months we will be in the awkward position where
>>>> HBase
>>>>>> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed,
>>>> this
>>>>>> may actually be a good time to revisit the decision to keep 4.x on
>> Java
>>>> 7.
>>>>>> 
>>>>>> All supported HBase versions support Java8. (Just checked)
>>>>>> 
>>>>>> Do we know of any major 4.x users (looking at SFDC mostly), who are
>>>> still
>>>>>> running HBase/Phoenix with Java 7, and plan to stay - and update
>>>> Phoenix
>>>>>> beyond 4.15.x - on it ?
>>>>>> 
>>>>>> How about bumping the Java requirement on 4.x to Java8 on with the
>>>> release
>>>>>> of 4.16 ?
>>>>>> 
>>>>>> This way we wouldn't take on  the backport problems with 4.15.x, but
>> we
>>>>>> would be able to use the new functionality in a reasonably timely
>>>> manner.
>>>>>> 
>>>>>> regards
>>>>>> Istvan
>>>>>> 
>>>>>> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com>
>>>> wrote:
>>>>>> 
>>>>>>> Thanks for the comments, Geoffrey.
>>>>>>> 
>>>>>>> I guess the option 3 is not preferred by anyone. For option 2, I did
>>>> not
>>>>>>> know community has discussed on this and the conclusion still holds
>>>>>> today.
>>>>>>> Glad to know. If timing is good, someone can reopen this conversation
>>>>>>> later.
>>>>>>> 
>>>>>>> On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Mingliang,
>>>>>>>> 
>>>>>>>> The topic's come up before, and in the past the conclusion has been
>>>> to
>>>>>>> keep
>>>>>>>> our Java requirements in line with the HBase dependency of a given
>>>>>>> branch.
>>>>>>>> Since HBase 1.x supports Java 7, and HBase compatibility guidelines
>>>>>> don't
>>>>>>>> allow for making JDK requirements more strict within a major
>>>> release,
>>>>>>> that
>>>>>>>> meant keeping Java 7 support on the 4.x branches which are of course
>>>>>>> based
>>>>>>>> on HBase 1.x. (And I don't see the 4.x line going away anytime
>>>> soon.)
>>>>>>>> 
>>>>>>>> We can always reopen that conversation about JDK support in light of
>>>>>> the
>>>>>>>> upcoming EOL, but so long as the requirement for Java 7 support is
>>>>>>> present,
>>>>>>>> I agree with Istvan that I wouldn't want large-scale changes between
>>>>>>> master
>>>>>>>> and 4.x based on JDK differences, because it's more work on both
>>>> patch
>>>>>>>> authors and committers the more they diverge. So I don't favor
>>>> Option
>>>>>> 2.
>>>>>>>> 
>>>>>>>> Geoffrey
>>>>>>>> 
>>>>>>>> On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I filed PHOENIX-5855 <
>>>>>>> https://issues.apache.org/jira/browse/PHOENIX-5855
>>>>>>>>> 
>>>>>>>>> to
>>>>>>>>> make the code more Java 8. This may apply to master branch only
>>>> and
>>>>>>>> Istvan
>>>>>>>>> Toth expressed concern about backporting conflicts.
>>>>>>>>> 
>>>>>>>>> I guess this is the trade-off between embracing newer Java
>>>> platform
>>>>>>>> (Java 7
>>>>>>>>> is EOL and will not be supported next year) and the effort of
>>>>>> resolving
>>>>>>>>> conflict if any when backporting.
>>>>>>>>> 
>>>>>>>>> The options are:
>>>>>>>>> 
>>>>>>>>>  1. get stuck in Java 7 for both master and all old branches. We
>>>>>> are
>>>>>>>>>  basically on this approach as I see Java 8 is used very
>>>>>> sparingly in
>>>>>>>>> master
>>>>>>>>>  branch
>>>>>>>>>  2. use Java 8 in master branch extensively and take care of
>>>> minor
>>>>>>>>>  conflicts if any for all 4.x branches. Patch author can provide
>>>>>>>> separate
>>>>>>>>>  patch if conflict is major, or make changes with less conflict.
>>>>>>>>>  3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older
>>>>>> branches
>>>>>>>> will
>>>>>>>>>  still need some manual fix as above.
>>>>>>>>> 
>>>>>>>>> I think it is the right time for option 2 or 3. Thoughts?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> --
>>>>>>>>> L
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> L
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> Andrew
>>>>> 
>>>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>>>> decrepit hands
>>>>>  - A23, Crosstalk
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Andrew
>>>> 
>>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>>> decrepit hands
>>>>  - A23, Crosstalk
>>>> 
>> 

Re: Are we embracing Java 8?

[Istvan Toth <st...@apache.org>]

Agreed, making this change only makes sense if we bump the source version,
and also compile Java 8 bytecode, which precludes Java7 support.
Cross-compiling to Java 7 would defeat the whole point of bumping the Java
version.

Re the test issue:

I am pretty sure that If we bump the Java version in the 4.x POM, then run
the standard test suite, it will test the very java compiler/runtime
combination that you are referring to.
Java 8 will be used to compile the Phoenix classes, The HBase and Hadoop
artifacts that maven pulls in will be Compiled with 1.7, and the Java
Runtime that runs all of this will be Java 8.

What testing do you have in mind that would be more thorough than that ?
We can run the test suite on a real HBase 1.3 cluster as well (most of it),
but since we have but one test suite, the only difference would be that
HBase and Java run in different JVMs.
(Of course, it would be useful, and probably worth doing, but it would be
fundamentally the same Java/JVM combination)

regards
Istvan

On Wed, Apr 22, 2020 at 7:29 AM Andrew Purtell <an...@gmail.com>
wrote:

> Yes, what I was trying to say is even if you don't adopt 8 language
> features and specify a source level of 7 when compiling the binaries, there
> will be other runtime issues. And so sure there's no reason to hold back on
> source level changes. The runtime compatibility story will change
> overnight.
>
> Regarding testing... Unless you think that someone won't download a HBase
> binary release (1.x will be compiled with 7), and then a future Phoenix
> binary release (compiled with 8), and then try to combine them, you should
> probably test that combination. (Smile.)
>
>
> > On Apr 21, 2020, at 9:44 PM, Istvan Toth <st...@apache.org> wrote:
> >
> > Hi!
> >
> > Actually, the convenience binaries would be the least of a (hypothetical)
> > Java7 user's problem.
> > The whole point of moving 4.x to Java8 would be to enable the usage of
> > Java8 features in the project,
> > so almost immediately the 4.x branch wouldn't even compile on 4.x .
> >
> > I would imagine that any installation still stuck on Java7 would be a
> > thoroughly legacy system where updating Phoenix is not a priority.
> >
> > I agree with the importance of having to thoroughly and prominently
> > document such a change.
> >
> > I am not sure that additional testing would be needed to test the
> HBase1.x
> > compiled with Java7 case,
> > AFAICT our IT suite would test exactly that case, as the HBase1.x
> artifacts
> > in Maven that the tests pull in are compiled on Java7.
> >
> > Miangliang is certainly not the only one who wants to use Java8 features.
> > This is a limitation that the old hands may be used to, but
> > is a pain point for bright-eyed new contributors. I know I've had to ask
> a
> > new dev to rewrite Java8 specific code multiple times,
> > not to mention having to rewrite my code on backport when I didn't
> realize
> > that the feature I used was Java8 specific.
> >
> > I can see these three outcomes:
> >
> > a. Switch 4.x to Java 8 now, and deal with the Java8->Java7 porting
> issues
> > on backporting to 4.15.x
> > b. Switch 4.x to Java 8 on the release on 4.16, thereby saving the
> > backporting issues on 4.15.x
> > c. Postpone switching to Java8 until HBase 1.x goes out of support.
> >
> > I know that no-one wants to commit to release dates, but do we even plan
> to
> > have a 4.16 release soon-ish ?
> > Based on historical release cadence, it could be anytime from next month
> to
> > next year.
> >
> > Having more or less established that no-one who is active on the dev list
> > cares about Java 7 for his/her own use,
> > how should we go forward with this ?
> >
> > Is this something that we should have a formal vote on ?
> >
> > Disclaimer: my employer doesn't support recent Phoenix 4.x versions, so
> my
> > opinions may be tinted by that.
> >
> > regards
> > Istvan
> >
> >> On Wed, Apr 22, 2020 at 3:50 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> Just to be super clear:
> >>
> >>> Compile the code with Java 8, then if someone tries to install the
> >> resulting binaries into a HBase convenience binary release 1.x, which
> will
> >> have been compiled with Java 7, the regionserver will abort.
> >>
> >> ... if the code is running on Java 7.
> >>
> >> I don't know if anyone is actually still running Java 7 anywhere, and
> >> wanting to use HBase and Phoenix on that runtime, but it's possible. We
> >> haven't tried to move up minimum Java version on HBase 1.x because it's
> >> impossible to know who is using it where, and originally it was released
> >> for/on 7. You can decide it is unlikely enough to move forward, but
> should
> >> at least document the implications somewhere on the release page.
> >>
> >> I'm pretty sure HBase compiled with 7 and Phoenix compiled with 8,
> running
> >> on 8 or later, will be stable, but this configuration obviously should
> be
> >> rigorously tested if you plan to move up.
> >>
> >> </eom>
> >>
> >>
> >> On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >>> The main problem you will face is the convenience binaries.
> >>>
> >>> If you are planning to move to Java 8, for 4.x branches, then you will
> no
> >>> longer be able to make binary convenience releases compatible with any
> >>> HBase 1.x convenience binary, even if you don't adopt any Java 8
> language
> >>> features. Compile the code with Java 8, then if someone tries to
> install
> >>> the resulting binaries into a HBase convenience binary release 1.x,
> which
> >>> will have been compiled with Java 7, the regionserver will abort.
> >>>
> >>> Java 8 is backwards compatible with Java 7. That is, if you compile
> with
> >>> Java 7 but run on a Java 8 runtime, all is good, even linkage in the
> JRE.
> >>>
> >>> Java 7 is not forwards compatible with Java 8, especially with respect
> to
> >>> JRE internals. What that means is if you compile something with Java 8,
> >>> even if you are not using Java 8 language features, you won't be able
> to
> >>> run it on a Java 7 runtime. Notably, there are linkage errors in the
> >>> j.u.concurrent package, which as you know both Phoenix and HBase use
> >>> extensively. I suppose this doesn't matter if you are adopting Java 8
> >>> language features anyway.
> >>>
> >>> Seems a big deal to move to source only releases for 4.x, but that is
> an
> >>> option.
> >>>
> >>>
> >>>> On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org>
> wrote:
> >>>
> >>>> Hi!
> >>>>
> >>>> Given that in a few months we will be in the awkward position where
> >> HBase
> >>>> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed,
> >> this
> >>>> may actually be a good time to revisit the decision to keep 4.x on
> Java
> >> 7.
> >>>>
> >>>> All supported HBase versions support Java8. (Just checked)
> >>>>
> >>>> Do we know of any major 4.x users (looking at SFDC mostly), who are
> >> still
> >>>> running HBase/Phoenix with Java 7, and plan to stay - and update
> >> Phoenix
> >>>> beyond 4.15.x - on it ?
> >>>>
> >>>> How about bumping the Java requirement on 4.x to Java8 on with the
> >> release
> >>>> of 4.16 ?
> >>>>
> >>>> This way we wouldn't take on  the backport problems with 4.15.x, but
> we
> >>>> would be able to use the new functionality in a reasonably timely
> >> manner.
> >>>>
> >>>> regards
> >>>> Istvan
> >>>>
> >>>> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Thanks for the comments, Geoffrey.
> >>>>>
> >>>>> I guess the option 3 is not preferred by anyone. For option 2, I did
> >> not
> >>>>> know community has discussed on this and the conclusion still holds
> >>>> today.
> >>>>> Glad to know. If timing is good, someone can reopen this conversation
> >>>>> later.
> >>>>>
> >>>>> On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Mingliang,
> >>>>>>
> >>>>>> The topic's come up before, and in the past the conclusion has been
> >> to
> >>>>> keep
> >>>>>> our Java requirements in line with the HBase dependency of a given
> >>>>> branch.
> >>>>>> Since HBase 1.x supports Java 7, and HBase compatibility guidelines
> >>>> don't
> >>>>>> allow for making JDK requirements more strict within a major
> >> release,
> >>>>> that
> >>>>>> meant keeping Java 7 support on the 4.x branches which are of course
> >>>>> based
> >>>>>> on HBase 1.x. (And I don't see the 4.x line going away anytime
> >> soon.)
> >>>>>>
> >>>>>> We can always reopen that conversation about JDK support in light of
> >>>> the
> >>>>>> upcoming EOL, but so long as the requirement for Java 7 support is
> >>>>> present,
> >>>>>> I agree with Istvan that I wouldn't want large-scale changes between
> >>>>> master
> >>>>>> and 4.x based on JDK differences, because it's more work on both
> >> patch
> >>>>>> authors and committers the more they diverge. So I don't favor
> >> Option
> >>>> 2.
> >>>>>>
> >>>>>> Geoffrey
> >>>>>>
> >>>>>> On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I filed PHOENIX-5855 <
> >>>>> https://issues.apache.org/jira/browse/PHOENIX-5855
> >>>>>>>
> >>>>>>> to
> >>>>>>> make the code more Java 8. This may apply to master branch only
> >> and
> >>>>>> Istvan
> >>>>>>> Toth expressed concern about backporting conflicts.
> >>>>>>>
> >>>>>>> I guess this is the trade-off between embracing newer Java
> >> platform
> >>>>>> (Java 7
> >>>>>>> is EOL and will not be supported next year) and the effort of
> >>>> resolving
> >>>>>>> conflict if any when backporting.
> >>>>>>>
> >>>>>>> The options are:
> >>>>>>>
> >>>>>>>   1. get stuck in Java 7 for both master and all old branches. We
> >>>> are
> >>>>>>>   basically on this approach as I see Java 8 is used very
> >>>> sparingly in
> >>>>>>> master
> >>>>>>>   branch
> >>>>>>>   2. use Java 8 in master branch extensively and take care of
> >> minor
> >>>>>>>   conflicts if any for all 4.x branches. Patch author can provide
> >>>>>> separate
> >>>>>>>   patch if conflict is major, or make changes with less conflict.
> >>>>>>>   3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older
> >>>> branches
> >>>>>> will
> >>>>>>>   still need some manual fix as above.
> >>>>>>>
> >>>>>>> I think it is the right time for option 2 or 3. Thoughts?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> --
> >>>>>>> L
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> L
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>> decrepit hands
> >>>   - A23, Crosstalk
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >>   - A23, Crosstalk
> >>
>

Re: Are we embracing Java 8?

[Andrew Purtell <an...@gmail.com>]

Yes, what I was trying to say is even if you don't adopt 8 language features and specify a source level of 7 when compiling the binaries, there will be other runtime issues. And so sure there's no reason to hold back on source level changes. The runtime compatibility story will change overnight. 

Regarding testing... Unless you think that someone won't download a HBase binary release (1.x will be compiled with 7), and then a future Phoenix binary release (compiled with 8), and then try to combine them, you should probably test that combination. (Smile.) 


> On Apr 21, 2020, at 9:44 PM, Istvan Toth <st...@apache.org> wrote:
> 
> Hi!
> 
> Actually, the convenience binaries would be the least of a (hypothetical)
> Java7 user's problem.
> The whole point of moving 4.x to Java8 would be to enable the usage of
> Java8 features in the project,
> so almost immediately the 4.x branch wouldn't even compile on 4.x .
> 
> I would imagine that any installation still stuck on Java7 would be a
> thoroughly legacy system where updating Phoenix is not a priority.
> 
> I agree with the importance of having to thoroughly and prominently
> document such a change.
> 
> I am not sure that additional testing would be needed to test the HBase1.x
> compiled with Java7 case,
> AFAICT our IT suite would test exactly that case, as the HBase1.x artifacts
> in Maven that the tests pull in are compiled on Java7.
> 
> Miangliang is certainly not the only one who wants to use Java8 features.
> This is a limitation that the old hands may be used to, but
> is a pain point for bright-eyed new contributors. I know I've had to ask a
> new dev to rewrite Java8 specific code multiple times,
> not to mention having to rewrite my code on backport when I didn't realize
> that the feature I used was Java8 specific.
> 
> I can see these three outcomes:
> 
> a. Switch 4.x to Java 8 now, and deal with the Java8->Java7 porting issues
> on backporting to 4.15.x
> b. Switch 4.x to Java 8 on the release on 4.16, thereby saving the
> backporting issues on 4.15.x
> c. Postpone switching to Java8 until HBase 1.x goes out of support.
> 
> I know that no-one wants to commit to release dates, but do we even plan to
> have a 4.16 release soon-ish ?
> Based on historical release cadence, it could be anytime from next month to
> next year.
> 
> Having more or less established that no-one who is active on the dev list
> cares about Java 7 for his/her own use,
> how should we go forward with this ?
> 
> Is this something that we should have a formal vote on ?
> 
> Disclaimer: my employer doesn't support recent Phoenix 4.x versions, so my
> opinions may be tinted by that.
> 
> regards
> Istvan
> 
>> On Wed, Apr 22, 2020 at 3:50 AM Andrew Purtell <ap...@apache.org> wrote:
>> 
>> Just to be super clear:
>> 
>>> Compile the code with Java 8, then if someone tries to install the
>> resulting binaries into a HBase convenience binary release 1.x, which will
>> have been compiled with Java 7, the regionserver will abort.
>> 
>> ... if the code is running on Java 7.
>> 
>> I don't know if anyone is actually still running Java 7 anywhere, and
>> wanting to use HBase and Phoenix on that runtime, but it's possible. We
>> haven't tried to move up minimum Java version on HBase 1.x because it's
>> impossible to know who is using it where, and originally it was released
>> for/on 7. You can decide it is unlikely enough to move forward, but should
>> at least document the implications somewhere on the release page.
>> 
>> I'm pretty sure HBase compiled with 7 and Phoenix compiled with 8, running
>> on 8 or later, will be stable, but this configuration obviously should be
>> rigorously tested if you plan to move up.
>> 
>> </eom>
>> 
>> 
>> On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell <ap...@apache.org>
>> wrote:
>> 
>>> The main problem you will face is the convenience binaries.
>>> 
>>> If you are planning to move to Java 8, for 4.x branches, then you will no
>>> longer be able to make binary convenience releases compatible with any
>>> HBase 1.x convenience binary, even if you don't adopt any Java 8 language
>>> features. Compile the code with Java 8, then if someone tries to install
>>> the resulting binaries into a HBase convenience binary release 1.x, which
>>> will have been compiled with Java 7, the regionserver will abort.
>>> 
>>> Java 8 is backwards compatible with Java 7. That is, if you compile with
>>> Java 7 but run on a Java 8 runtime, all is good, even linkage in the JRE.
>>> 
>>> Java 7 is not forwards compatible with Java 8, especially with respect to
>>> JRE internals. What that means is if you compile something with Java 8,
>>> even if you are not using Java 8 language features, you won't be able to
>>> run it on a Java 7 runtime. Notably, there are linkage errors in the
>>> j.u.concurrent package, which as you know both Phoenix and HBase use
>>> extensively. I suppose this doesn't matter if you are adopting Java 8
>>> language features anyway.
>>> 
>>> Seems a big deal to move to source only releases for 4.x, but that is an
>>> option.
>>> 
>>> 
>>>> On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org> wrote:
>>> 
>>>> Hi!
>>>> 
>>>> Given that in a few months we will be in the awkward position where
>> HBase
>>>> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed,
>> this
>>>> may actually be a good time to revisit the decision to keep 4.x on Java
>> 7.
>>>> 
>>>> All supported HBase versions support Java8. (Just checked)
>>>> 
>>>> Do we know of any major 4.x users (looking at SFDC mostly), who are
>> still
>>>> running HBase/Phoenix with Java 7, and plan to stay - and update
>> Phoenix
>>>> beyond 4.15.x - on it ?
>>>> 
>>>> How about bumping the Java requirement on 4.x to Java8 on with the
>> release
>>>> of 4.16 ?
>>>> 
>>>> This way we wouldn't take on  the backport problems with 4.15.x, but we
>>>> would be able to use the new functionality in a reasonably timely
>> manner.
>>>> 
>>>> regards
>>>> Istvan
>>>> 
>>>> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com>
>> wrote:
>>>> 
>>>>> Thanks for the comments, Geoffrey.
>>>>> 
>>>>> I guess the option 3 is not preferred by anyone. For option 2, I did
>> not
>>>>> know community has discussed on this and the conclusion still holds
>>>> today.
>>>>> Glad to know. If timing is good, someone can reopen this conversation
>>>>> later.
>>>>> 
>>>>> On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> Mingliang,
>>>>>> 
>>>>>> The topic's come up before, and in the past the conclusion has been
>> to
>>>>> keep
>>>>>> our Java requirements in line with the HBase dependency of a given
>>>>> branch.
>>>>>> Since HBase 1.x supports Java 7, and HBase compatibility guidelines
>>>> don't
>>>>>> allow for making JDK requirements more strict within a major
>> release,
>>>>> that
>>>>>> meant keeping Java 7 support on the 4.x branches which are of course
>>>>> based
>>>>>> on HBase 1.x. (And I don't see the 4.x line going away anytime
>> soon.)
>>>>>> 
>>>>>> We can always reopen that conversation about JDK support in light of
>>>> the
>>>>>> upcoming EOL, but so long as the requirement for Java 7 support is
>>>>> present,
>>>>>> I agree with Istvan that I wouldn't want large-scale changes between
>>>>> master
>>>>>> and 4.x based on JDK differences, because it's more work on both
>> patch
>>>>>> authors and committers the more they diverge. So I don't favor
>> Option
>>>> 2.
>>>>>> 
>>>>>> Geoffrey
>>>>>> 
>>>>>> On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I filed PHOENIX-5855 <
>>>>> https://issues.apache.org/jira/browse/PHOENIX-5855
>>>>>>> 
>>>>>>> to
>>>>>>> make the code more Java 8. This may apply to master branch only
>> and
>>>>>> Istvan
>>>>>>> Toth expressed concern about backporting conflicts.
>>>>>>> 
>>>>>>> I guess this is the trade-off between embracing newer Java
>> platform
>>>>>> (Java 7
>>>>>>> is EOL and will not be supported next year) and the effort of
>>>> resolving
>>>>>>> conflict if any when backporting.
>>>>>>> 
>>>>>>> The options are:
>>>>>>> 
>>>>>>>   1. get stuck in Java 7 for both master and all old branches. We
>>>> are
>>>>>>>   basically on this approach as I see Java 8 is used very
>>>> sparingly in
>>>>>>> master
>>>>>>>   branch
>>>>>>>   2. use Java 8 in master branch extensively and take care of
>> minor
>>>>>>>   conflicts if any for all 4.x branches. Patch author can provide
>>>>>> separate
>>>>>>>   patch if conflict is major, or make changes with less conflict.
>>>>>>>   3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older
>>>> branches
>>>>>> will
>>>>>>>   still need some manual fix as above.
>>>>>>> 
>>>>>>> I think it is the right time for option 2 or 3. Thoughts?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> --
>>>>>>> L
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> L
>>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Andrew
>>> 
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>>   - A23, Crosstalk
>>> 
>> 
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk
>> 

Re: Are we embracing Java 8?

[Istvan Toth <st...@apache.org>]

Hi!

Actually, the convenience binaries would be the least of a (hypothetical)
Java7 user's problem.
The whole point of moving 4.x to Java8 would be to enable the usage of
Java8 features in the project,
so almost immediately the 4.x branch wouldn't even compile on 4.x .

I would imagine that any installation still stuck on Java7 would be a
thoroughly legacy system where updating Phoenix is not a priority.

I agree with the importance of having to thoroughly and prominently
document such a change.

I am not sure that additional testing would be needed to test the HBase1.x
compiled with Java7 case,
AFAICT our IT suite would test exactly that case, as the HBase1.x artifacts
in Maven that the tests pull in are compiled on Java7.

Miangliang is certainly not the only one who wants to use Java8 features.
This is a limitation that the old hands may be used to, but
is a pain point for bright-eyed new contributors. I know I've had to ask a
new dev to rewrite Java8 specific code multiple times,
not to mention having to rewrite my code on backport when I didn't realize
that the feature I used was Java8 specific.

I can see these three outcomes:

a. Switch 4.x to Java 8 now, and deal with the Java8->Java7 porting issues
on backporting to 4.15.x
b. Switch 4.x to Java 8 on the release on 4.16, thereby saving the
backporting issues on 4.15.x
c. Postpone switching to Java8 until HBase 1.x goes out of support.

I know that no-one wants to commit to release dates, but do we even plan to
have a 4.16 release soon-ish ?
Based on historical release cadence, it could be anytime from next month to
next year.

Having more or less established that no-one who is active on the dev list
cares about Java 7 for his/her own use,
how should we go forward with this ?

Is this something that we should have a formal vote on ?

Disclaimer: my employer doesn't support recent Phoenix 4.x versions, so my
opinions may be tinted by that.

regards
Istvan

On Wed, Apr 22, 2020 at 3:50 AM Andrew Purtell <ap...@apache.org> wrote:

> Just to be super clear:
>
> > Compile the code with Java 8, then if someone tries to install the
> resulting binaries into a HBase convenience binary release 1.x, which will
> have been compiled with Java 7, the regionserver will abort.
>
> ... if the code is running on Java 7.
>
> I don't know if anyone is actually still running Java 7 anywhere, and
> wanting to use HBase and Phoenix on that runtime, but it's possible. We
> haven't tried to move up minimum Java version on HBase 1.x because it's
> impossible to know who is using it where, and originally it was released
> for/on 7. You can decide it is unlikely enough to move forward, but should
> at least document the implications somewhere on the release page.
>
> I'm pretty sure HBase compiled with 7 and Phoenix compiled with 8, running
> on 8 or later, will be stable, but this configuration obviously should be
> rigorously tested if you plan to move up.
>
> </eom>
>
>
> On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > The main problem you will face is the convenience binaries.
> >
> > If you are planning to move to Java 8, for 4.x branches, then you will no
> > longer be able to make binary convenience releases compatible with any
> > HBase 1.x convenience binary, even if you don't adopt any Java 8 language
> > features. Compile the code with Java 8, then if someone tries to install
> > the resulting binaries into a HBase convenience binary release 1.x, which
> > will have been compiled with Java 7, the regionserver will abort.
> >
> > Java 8 is backwards compatible with Java 7. That is, if you compile with
> > Java 7 but run on a Java 8 runtime, all is good, even linkage in the JRE.
> >
> > Java 7 is not forwards compatible with Java 8, especially with respect to
> > JRE internals. What that means is if you compile something with Java 8,
> > even if you are not using Java 8 language features, you won't be able to
> > run it on a Java 7 runtime. Notably, there are linkage errors in the
> > j.u.concurrent package, which as you know both Phoenix and HBase use
> > extensively. I suppose this doesn't matter if you are adopting Java 8
> > language features anyway.
> >
> > Seems a big deal to move to source only releases for 4.x, but that is an
> > option.
> >
> >
> > On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org> wrote:
> >
> >> Hi!
> >>
> >> Given that in a few months we will be in the awkward position where
> HBase
> >> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed,
> this
> >> may actually be a good time to revisit the decision to keep 4.x on Java
> 7.
> >>
> >> All supported HBase versions support Java8. (Just checked)
> >>
> >> Do we know of any major 4.x users (looking at SFDC mostly), who are
> still
> >> running HBase/Phoenix with Java 7, and plan to stay - and update
> Phoenix
> >> beyond 4.15.x - on it ?
> >>
> >> How about bumping the Java requirement on 4.x to Java8 on with the
> release
> >> of 4.16 ?
> >>
> >> This way we wouldn't take on  the backport problems with 4.15.x, but we
> >> would be able to use the new functionality in a reasonably timely
> manner.
> >>
> >> regards
> >> Istvan
> >>
> >> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com>
> wrote:
> >>
> >> > Thanks for the comments, Geoffrey.
> >> >
> >> > I guess the option 3 is not preferred by anyone. For option 2, I did
> not
> >> > know community has discussed on this and the conclusion still holds
> >> today.
> >> > Glad to know. If timing is good, someone can reopen this conversation
> >> > later.
> >> >
> >> > On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
> >> > wrote:
> >> >
> >> > > Mingliang,
> >> > >
> >> > > The topic's come up before, and in the past the conclusion has been
> to
> >> > keep
> >> > > our Java requirements in line with the HBase dependency of a given
> >> > branch.
> >> > > Since HBase 1.x supports Java 7, and HBase compatibility guidelines
> >> don't
> >> > > allow for making JDK requirements more strict within a major
> release,
> >> > that
> >> > > meant keeping Java 7 support on the 4.x branches which are of course
> >> > based
> >> > > on HBase 1.x. (And I don't see the 4.x line going away anytime
> soon.)
> >> > >
> >> > > We can always reopen that conversation about JDK support in light of
> >> the
> >> > > upcoming EOL, but so long as the requirement for Java 7 support is
> >> > present,
> >> > > I agree with Istvan that I wouldn't want large-scale changes between
> >> > master
> >> > > and 4.x based on JDK differences, because it's more work on both
> patch
> >> > > authors and committers the more they diverge. So I don't favor
> Option
> >> 2.
> >> > >
> >> > > Geoffrey
> >> > >
> >> > > On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I filed PHOENIX-5855 <
> >> > https://issues.apache.org/jira/browse/PHOENIX-5855
> >> > > >
> >> > > > to
> >> > > > make the code more Java 8. This may apply to master branch only
> and
> >> > > Istvan
> >> > > > Toth expressed concern about backporting conflicts.
> >> > > >
> >> > > > I guess this is the trade-off between embracing newer Java
> platform
> >> > > (Java 7
> >> > > > is EOL and will not be supported next year) and the effort of
> >> resolving
> >> > > > conflict if any when backporting.
> >> > > >
> >> > > > The options are:
> >> > > >
> >> > > >    1. get stuck in Java 7 for both master and all old branches. We
> >> are
> >> > > >    basically on this approach as I see Java 8 is used very
> >> sparingly in
> >> > > > master
> >> > > >    branch
> >> > > >    2. use Java 8 in master branch extensively and take care of
> minor
> >> > > >    conflicts if any for all 4.x branches. Patch author can provide
> >> > > separate
> >> > > >    patch if conflict is major, or make changes with less conflict.
> >> > > >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older
> >> branches
> >> > > will
> >> > > >    still need some manual fix as above.
> >> > > >
> >> > > > I think it is the right time for option 2 or 3. Thoughts?
> >> > > >
> >> > > > Thanks,
> >> > > > --
> >> > > > L
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > L
> >> >
> >>
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: Are we embracing Java 8?

[Andrew Purtell <ap...@apache.org>]

Just to be super clear:

> Compile the code with Java 8, then if someone tries to install the
resulting binaries into a HBase convenience binary release 1.x, which will
have been compiled with Java 7, the regionserver will abort.

... if the code is running on Java 7.

I don't know if anyone is actually still running Java 7 anywhere, and
wanting to use HBase and Phoenix on that runtime, but it's possible. We
haven't tried to move up minimum Java version on HBase 1.x because it's
impossible to know who is using it where, and originally it was released
for/on 7. You can decide it is unlikely enough to move forward, but should
at least document the implications somewhere on the release page.

I'm pretty sure HBase compiled with 7 and Phoenix compiled with 8, running
on 8 or later, will be stable, but this configuration obviously should be
rigorously tested if you plan to move up.

</eom>


On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell <ap...@apache.org> wrote:

> The main problem you will face is the convenience binaries.
>
> If you are planning to move to Java 8, for 4.x branches, then you will no
> longer be able to make binary convenience releases compatible with any
> HBase 1.x convenience binary, even if you don't adopt any Java 8 language
> features. Compile the code with Java 8, then if someone tries to install
> the resulting binaries into a HBase convenience binary release 1.x, which
> will have been compiled with Java 7, the regionserver will abort.
>
> Java 8 is backwards compatible with Java 7. That is, if you compile with
> Java 7 but run on a Java 8 runtime, all is good, even linkage in the JRE.
>
> Java 7 is not forwards compatible with Java 8, especially with respect to
> JRE internals. What that means is if you compile something with Java 8,
> even if you are not using Java 8 language features, you won't be able to
> run it on a Java 7 runtime. Notably, there are linkage errors in the
> j.u.concurrent package, which as you know both Phoenix and HBase use
> extensively. I suppose this doesn't matter if you are adopting Java 8
> language features anyway.
>
> Seems a big deal to move to source only releases for 4.x, but that is an
> option.
>
>
> On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org> wrote:
>
>> Hi!
>>
>> Given that in a few months we will be in the awkward position where HBase
>> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed, this
>> may actually be a good time to revisit the decision to keep 4.x on Java 7.
>>
>> All supported HBase versions support Java8. (Just checked)
>>
>> Do we know of any major 4.x users (looking at SFDC mostly), who are still
>> running HBase/Phoenix with Java 7, and plan to stay - and update  Phoenix
>> beyond 4.15.x - on it ?
>>
>> How about bumping the Java requirement on 4.x to Java8 on with the release
>> of 4.16 ?
>>
>> This way we wouldn't take on  the backport problems with 4.15.x, but we
>> would be able to use the new functionality in a reasonably timely manner.
>>
>> regards
>> Istvan
>>
>> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com> wrote:
>>
>> > Thanks for the comments, Geoffrey.
>> >
>> > I guess the option 3 is not preferred by anyone. For option 2, I did not
>> > know community has discussed on this and the conclusion still holds
>> today.
>> > Glad to know. If timing is good, someone can reopen this conversation
>> > later.
>> >
>> > On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
>> > wrote:
>> >
>> > > Mingliang,
>> > >
>> > > The topic's come up before, and in the past the conclusion has been to
>> > keep
>> > > our Java requirements in line with the HBase dependency of a given
>> > branch.
>> > > Since HBase 1.x supports Java 7, and HBase compatibility guidelines
>> don't
>> > > allow for making JDK requirements more strict within a major release,
>> > that
>> > > meant keeping Java 7 support on the 4.x branches which are of course
>> > based
>> > > on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)
>> > >
>> > > We can always reopen that conversation about JDK support in light of
>> the
>> > > upcoming EOL, but so long as the requirement for Java 7 support is
>> > present,
>> > > I agree with Istvan that I wouldn't want large-scale changes between
>> > master
>> > > and 4.x based on JDK differences, because it's more work on both patch
>> > > authors and committers the more they diverge. So I don't favor Option
>> 2.
>> > >
>> > > Geoffrey
>> > >
>> > > On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
>> > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I filed PHOENIX-5855 <
>> > https://issues.apache.org/jira/browse/PHOENIX-5855
>> > > >
>> > > > to
>> > > > make the code more Java 8. This may apply to master branch only and
>> > > Istvan
>> > > > Toth expressed concern about backporting conflicts.
>> > > >
>> > > > I guess this is the trade-off between embracing newer Java platform
>> > > (Java 7
>> > > > is EOL and will not be supported next year) and the effort of
>> resolving
>> > > > conflict if any when backporting.
>> > > >
>> > > > The options are:
>> > > >
>> > > >    1. get stuck in Java 7 for both master and all old branches. We
>> are
>> > > >    basically on this approach as I see Java 8 is used very
>> sparingly in
>> > > > master
>> > > >    branch
>> > > >    2. use Java 8 in master branch extensively and take care of minor
>> > > >    conflicts if any for all 4.x branches. Patch author can provide
>> > > separate
>> > > >    patch if conflict is major, or make changes with less conflict.
>> > > >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older
>> branches
>> > > will
>> > > >    still need some manual fix as above.
>> > > >
>> > > > I think it is the right time for option 2 or 3. Thoughts?
>> > > >
>> > > > Thanks,
>> > > > --
>> > > > L
>> > > >
>> > >
>> >
>> >
>> > --
>> > L
>> >
>>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Are we embracing Java 8?

[Andrew Purtell <ap...@apache.org>]

The main problem you will face is the convenience binaries.

If you are planning to move to Java 8, for 4.x branches, then you will no
longer be able to make binary convenience releases compatible with any
HBase 1.x convenience binary, even if you don't adopt any Java 8 language
features. Compile the code with Java 8, then if someone tries to install
the resulting binaries into a HBase convenience binary release 1.x, which
will have been compiled with Java 7, the regionserver will abort.

Java 8 is backwards compatible with Java 7. That is, if you compile with
Java 7 but run on a Java 8 runtime, all is good, even linkage in the JRE.

Java 7 is not forwards compatible with Java 8, especially with respect to
JRE internals. What that means is if you compile something with Java 8,
even if you are not using Java 8 language features, you won't be able to
run it on a Java 7 runtime. Notably, there are linkage errors in the
j.u.concurrent package, which as you know both Phoenix and HBase use
extensively. I suppose this doesn't matter if you are adopting Java 8
language features anyway.

Seems a big deal to move to source only releases for 4.x, but that is an
option.


On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org> wrote:

> Hi!
>
> Given that in a few months we will be in the awkward position where HBase
> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed, this
> may actually be a good time to revisit the decision to keep 4.x on Java 7.
>
> All supported HBase versions support Java8. (Just checked)
>
> Do we know of any major 4.x users (looking at SFDC mostly), who are still
> running HBase/Phoenix with Java 7, and plan to stay - and update  Phoenix
> beyond 4.15.x - on it ?
>
> How about bumping the Java requirement on 4.x to Java8 on with the release
> of 4.16 ?
>
> This way we wouldn't take on  the backport problems with 4.15.x, but we
> would be able to use the new functionality in a reasonably timely manner.
>
> regards
> Istvan
>
> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com> wrote:
>
> > Thanks for the comments, Geoffrey.
> >
> > I guess the option 3 is not preferred by anyone. For option 2, I did not
> > know community has discussed on this and the conclusion still holds
> today.
> > Glad to know. If timing is good, someone can reopen this conversation
> > later.
> >
> > On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
> > wrote:
> >
> > > Mingliang,
> > >
> > > The topic's come up before, and in the past the conclusion has been to
> > keep
> > > our Java requirements in line with the HBase dependency of a given
> > branch.
> > > Since HBase 1.x supports Java 7, and HBase compatibility guidelines
> don't
> > > allow for making JDK requirements more strict within a major release,
> > that
> > > meant keeping Java 7 support on the 4.x branches which are of course
> > based
> > > on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)
> > >
> > > We can always reopen that conversation about JDK support in light of
> the
> > > upcoming EOL, but so long as the requirement for Java 7 support is
> > present,
> > > I agree with Istvan that I wouldn't want large-scale changes between
> > master
> > > and 4.x based on JDK differences, because it's more work on both patch
> > > authors and committers the more they diverge. So I don't favor Option
> 2.
> > >
> > > Geoffrey
> > >
> > > On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I filed PHOENIX-5855 <
> > https://issues.apache.org/jira/browse/PHOENIX-5855
> > > >
> > > > to
> > > > make the code more Java 8. This may apply to master branch only and
> > > Istvan
> > > > Toth expressed concern about backporting conflicts.
> > > >
> > > > I guess this is the trade-off between embracing newer Java platform
> > > (Java 7
> > > > is EOL and will not be supported next year) and the effort of
> resolving
> > > > conflict if any when backporting.
> > > >
> > > > The options are:
> > > >
> > > >    1. get stuck in Java 7 for both master and all old branches. We
> are
> > > >    basically on this approach as I see Java 8 is used very sparingly
> in
> > > > master
> > > >    branch
> > > >    2. use Java 8 in master branch extensively and take care of minor
> > > >    conflicts if any for all 4.x branches. Patch author can provide
> > > separate
> > > >    patch if conflict is major, or make changes with less conflict.
> > > >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches
> > > will
> > > >    still need some manual fix as above.
> > > >
> > > > I think it is the right time for option 2 or 3. Thoughts?
> > > >
> > > > Thanks,
> > > > --
> > > > L
> > > >
> > >
> >
> >
> > --
> > L
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Are we embracing Java 8?

[Mingliang Liu <li...@gmail.com>]

> All supported HBase versions support Java8. (Just checked)

Good point Istvan. I was not aware of that. If so I'll think option 3 is
still on the table for Java 8 adoption in Phoenix.

> Do we know of any major 4.x users (looking at SFDC mostly), who are still
> running HBase/Phoenix with Java 7

I don't think Java 7 is still a thing at SFDC (disclaimer: yes I work here).

On Fri, Apr 17, 2020 at 10:18 PM Istvan Toth <st...@apache.org> wrote:

> Hi!
>
> Given that in a few months we will be in the awkward position where HBase
> 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed, this
> may actually be a good time to revisit the decision to keep 4.x on Java 7.
>
> All supported HBase versions support Java8. (Just checked)
>
> Do we know of any major 4.x users (looking at SFDC mostly), who are still
> running HBase/Phoenix with Java 7, and plan to stay - and update  Phoenix
> beyond 4.15.x - on it ?
>
> How about bumping the Java requirement on 4.x to Java8 on with the release
> of 4.16 ?
>
> This way we wouldn't take on  the backport problems with 4.15.x, but we
> would be able to use the new functionality in a reasonably timely manner.
>
> regards
> Istvan
>
> On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com> wrote:
>
> > Thanks for the comments, Geoffrey.
> >
> > I guess the option 3 is not preferred by anyone. For option 2, I did not
> > know community has discussed on this and the conclusion still holds
> today.
> > Glad to know. If timing is good, someone can reopen this conversation
> > later.
> >
> > On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
> > wrote:
> >
> > > Mingliang,
> > >
> > > The topic's come up before, and in the past the conclusion has been to
> > keep
> > > our Java requirements in line with the HBase dependency of a given
> > branch.
> > > Since HBase 1.x supports Java 7, and HBase compatibility guidelines
> don't
> > > allow for making JDK requirements more strict within a major release,
> > that
> > > meant keeping Java 7 support on the 4.x branches which are of course
> > based
> > > on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)
> > >
> > > We can always reopen that conversation about JDK support in light of
> the
> > > upcoming EOL, but so long as the requirement for Java 7 support is
> > present,
> > > I agree with Istvan that I wouldn't want large-scale changes between
> > master
> > > and 4.x based on JDK differences, because it's more work on both patch
> > > authors and committers the more they diverge. So I don't favor Option
> 2.
> > >
> > > Geoffrey
> > >
> > > On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I filed PHOENIX-5855 <
> > https://issues.apache.org/jira/browse/PHOENIX-5855
> > > >
> > > > to
> > > > make the code more Java 8. This may apply to master branch only and
> > > Istvan
> > > > Toth expressed concern about backporting conflicts.
> > > >
> > > > I guess this is the trade-off between embracing newer Java platform
> > > (Java 7
> > > > is EOL and will not be supported next year) and the effort of
> resolving
> > > > conflict if any when backporting.
> > > >
> > > > The options are:
> > > >
> > > >    1. get stuck in Java 7 for both master and all old branches. We
> are
> > > >    basically on this approach as I see Java 8 is used very sparingly
> in
> > > > master
> > > >    branch
> > > >    2. use Java 8 in master branch extensively and take care of minor
> > > >    conflicts if any for all 4.x branches. Patch author can provide
> > > separate
> > > >    patch if conflict is major, or make changes with less conflict.
> > > >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches
> > > will
> > > >    still need some manual fix as above.
> > > >
> > > > I think it is the right time for option 2 or 3. Thoughts?
> > > >
> > > > Thanks,
> > > > --
> > > > L
> > > >
> > >
> >
> >
> > --
> > L
> >
>


-- 
L

Re: Are we embracing Java 8?

[Istvan Toth <st...@apache.org>]

Hi!

Given that in a few months we will be in the awkward position where HBase
1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed, this
may actually be a good time to revisit the decision to keep 4.x on Java 7.

All supported HBase versions support Java8. (Just checked)

Do we know of any major 4.x users (looking at SFDC mostly), who are still
running HBase/Phoenix with Java 7, and plan to stay - and update  Phoenix
beyond 4.15.x - on it ?

How about bumping the Java requirement on 4.x to Java8 on with the release
of 4.16 ?

This way we wouldn't take on  the backport problems with 4.15.x, but we
would be able to use the new functionality in a reasonably timely manner.

regards
Istvan

On Sat, Apr 18, 2020 at 1:17 AM Mingliang Liu <li...@gmail.com> wrote:

> Thanks for the comments, Geoffrey.
>
> I guess the option 3 is not preferred by anyone. For option 2, I did not
> know community has discussed on this and the conclusion still holds today.
> Glad to know. If timing is good, someone can reopen this conversation
> later.
>
> On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org>
> wrote:
>
> > Mingliang,
> >
> > The topic's come up before, and in the past the conclusion has been to
> keep
> > our Java requirements in line with the HBase dependency of a given
> branch.
> > Since HBase 1.x supports Java 7, and HBase compatibility guidelines don't
> > allow for making JDK requirements more strict within a major release,
> that
> > meant keeping Java 7 support on the 4.x branches which are of course
> based
> > on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)
> >
> > We can always reopen that conversation about JDK support in light of the
> > upcoming EOL, but so long as the requirement for Java 7 support is
> present,
> > I agree with Istvan that I wouldn't want large-scale changes between
> master
> > and 4.x based on JDK differences, because it's more work on both patch
> > authors and committers the more they diverge. So I don't favor Option 2.
> >
> > Geoffrey
> >
> > On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > I filed PHOENIX-5855 <
> https://issues.apache.org/jira/browse/PHOENIX-5855
> > >
> > > to
> > > make the code more Java 8. This may apply to master branch only and
> > Istvan
> > > Toth expressed concern about backporting conflicts.
> > >
> > > I guess this is the trade-off between embracing newer Java platform
> > (Java 7
> > > is EOL and will not be supported next year) and the effort of resolving
> > > conflict if any when backporting.
> > >
> > > The options are:
> > >
> > >    1. get stuck in Java 7 for both master and all old branches. We are
> > >    basically on this approach as I see Java 8 is used very sparingly in
> > > master
> > >    branch
> > >    2. use Java 8 in master branch extensively and take care of minor
> > >    conflicts if any for all 4.x branches. Patch author can provide
> > separate
> > >    patch if conflict is major, or make changes with less conflict.
> > >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches
> > will
> > >    still need some manual fix as above.
> > >
> > > I think it is the right time for option 2 or 3. Thoughts?
> > >
> > > Thanks,
> > > --
> > > L
> > >
> >
>
>
> --
> L
>

Re: Are we embracing Java 8?

[Mingliang Liu <li...@gmail.com>]

Thanks for the comments, Geoffrey.

I guess the option 3 is not preferred by anyone. For option 2, I did not
know community has discussed on this and the conclusion still holds today.
Glad to know. If timing is good, someone can reopen this conversation
later.

On Fri, Apr 17, 2020 at 1:32 PM Geoffrey Jacoby <gj...@apache.org> wrote:

> Mingliang,
>
> The topic's come up before, and in the past the conclusion has been to keep
> our Java requirements in line with the HBase dependency of a given branch.
> Since HBase 1.x supports Java 7, and HBase compatibility guidelines don't
> allow for making JDK requirements more strict within a major release, that
> meant keeping Java 7 support on the 4.x branches which are of course based
> on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)
>
> We can always reopen that conversation about JDK support in light of the
> upcoming EOL, but so long as the requirement for Java 7 support is present,
> I agree with Istvan that I wouldn't want large-scale changes between master
> and 4.x based on JDK differences, because it's more work on both patch
> authors and committers the more they diverge. So I don't favor Option 2.
>
> Geoffrey
>
> On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com> wrote:
>
> > Hi,
> >
> > I filed PHOENIX-5855 <https://issues.apache.org/jira/browse/PHOENIX-5855
> >
> > to
> > make the code more Java 8. This may apply to master branch only and
> Istvan
> > Toth expressed concern about backporting conflicts.
> >
> > I guess this is the trade-off between embracing newer Java platform
> (Java 7
> > is EOL and will not be supported next year) and the effort of resolving
> > conflict if any when backporting.
> >
> > The options are:
> >
> >    1. get stuck in Java 7 for both master and all old branches. We are
> >    basically on this approach as I see Java 8 is used very sparingly in
> > master
> >    branch
> >    2. use Java 8 in master branch extensively and take care of minor
> >    conflicts if any for all 4.x branches. Patch author can provide
> separate
> >    patch if conflict is major, or make changes with less conflict.
> >    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches
> will
> >    still need some manual fix as above.
> >
> > I think it is the right time for option 2 or 3. Thoughts?
> >
> > Thanks,
> > --
> > L
> >
>


-- 
L

Re: Are we embracing Java 8?

[Geoffrey Jacoby <gj...@apache.org>]

Mingliang,

The topic's come up before, and in the past the conclusion has been to keep
our Java requirements in line with the HBase dependency of a given branch.
Since HBase 1.x supports Java 7, and HBase compatibility guidelines don't
allow for making JDK requirements more strict within a major release, that
meant keeping Java 7 support on the 4.x branches which are of course based
on HBase 1.x. (And I don't see the 4.x line going away anytime soon.)

We can always reopen that conversation about JDK support in light of the
upcoming EOL, but so long as the requirement for Java 7 support is present,
I agree with Istvan that I wouldn't want large-scale changes between master
and 4.x based on JDK differences, because it's more work on both patch
authors and committers the more they diverge. So I don't favor Option 2.

Geoffrey

On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <li...@gmail.com> wrote:

> Hi,
>
> I filed PHOENIX-5855 <https://issues.apache.org/jira/browse/PHOENIX-5855>
> to
> make the code more Java 8. This may apply to master branch only and Istvan
> Toth expressed concern about backporting conflicts.
>
> I guess this is the trade-off between embracing newer Java platform (Java 7
> is EOL and will not be supported next year) and the effort of resolving
> conflict if any when backporting.
>
> The options are:
>
>    1. get stuck in Java 7 for both master and all old branches. We are
>    basically on this approach as I see Java 8 is used very sparingly in
> master
>    branch
>    2. use Java 8 in master branch extensively and take care of minor
>    conflicts if any for all 4.x branches. Patch author can provide separate
>    patch if conflict is major, or make changes with less conflict.
>    3. bump 4.16 (or 4.15.1?) to Java 8. Backporting to older branches will
>    still need some manual fix as above.
>
> I think it is the right time for option 2 or 3. Thoughts?
>
> Thanks,
> --
> L
>