phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Are we embracing Java 8?
Date Wed, 22 Apr 2020 01:44:36 GMT
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 <stoty@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 <liuml07@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 <gjacoby@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 <liuml07@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

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