> 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 <lium...@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 <gjac...@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 <lium...@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
