phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Istvan Toth <st...@apache.org>
Subject Re: Are we embracing Java 8?
Date Wed, 22 Apr 2020 04:44:19 GMT
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 <apurtell@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 <apurtell@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 <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
> >
>
>
> --
> 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