Agreed, making this change only makes sense if we bump the source version, and also compile Java 8 bytecode, which precludes Java7 support. Cross-compiling to Java 7 would defeat the whole point of bumping the Java version.
Re the test issue: I am pretty sure that If we bump the Java version in the 4.x POM, then run the standard test suite, it will test the very java compiler/runtime combination that you are referring to. Java 8 will be used to compile the Phoenix classes, The HBase and Hadoop artifacts that maven pulls in will be Compiled with 1.7, and the Java Runtime that runs all of this will be Java 8. What testing do you have in mind that would be more thorough than that ? We can run the test suite on a real HBase 1.3 cluster as well (most of it), but since we have but one test suite, the only difference would be that HBase and Java run in different JVMs. (Of course, it would be useful, and probably worth doing, but it would be fundamentally the same Java/JVM combination) regards Istvan On Wed, Apr 22, 2020 at 7:29 AM Andrew Purtell <andrew.purt...@gmail.com> wrote: > Yes, what I was trying to say is even if you don't adopt 8 language > features and specify a source level of 7 when compiling the binaries, there > will be other runtime issues. And so sure there's no reason to hold back on > source level changes. The runtime compatibility story will change > overnight. > > Regarding testing... Unless you think that someone won't download a HBase > binary release (1.x will be compiled with 7), and then a future Phoenix > binary release (compiled with 8), and then try to combine them, you should > probably test that combination. (Smile.) > > > > On Apr 21, 2020, at 9:44 PM, Istvan Toth <st...@apache.org> wrote: > > > > 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 <apurt...@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 <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 > >> >
