phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Jacoby <>
Subject Re: Are we embracing Java 8?
Date Fri, 17 Apr 2020 20:32:46 GMT

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.


On Fri, Apr 17, 2020 at 12:27 PM Mingliang Liu <> wrote:

> Hi,
> I filed 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message