Yes, a real cluster, ideally a real application. With some stress. Some scale too if it can be managed.
> On Apr 22, 2020, at 6:10 AM, Istvan Toth <st...@apache.org> wrote: > > 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 >>>> >>
