phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Are we embracing Java 8?
Date Wed, 22 Apr 2020 16:06:57 GMT
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 <stoty@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.purtell@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 <stoty@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 <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
View raw message