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 <apurt...@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 <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 >> > >> > > > -- > 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
