That sounds like a fine plan for Phoenix to do. Please no changing minimum jdk requirements for HBase in minor releases.
It's bad enough that we had to give up on Hadoop compatibility for minor releases. I'm sure it's only a matter of time before that puts us in a bad spot wrt JDK support. On Tue, Dec 4, 2018, 19:05 Thomas D'Silva <tdsi...@salesforce.com wrote: > I think Phoenix might end up moving the connector modules (spark, kakfa > etc) and the query server into a separate repos > so that they can be compiled with Java 8. Phoenix core would continue to > maintain the same java version compatibility as HBase. > > > On Tue, Dec 4, 2018 at 4:37 PM Andrew Purtell <apurt...@apache.org> wrote: > > > I'm not taking a position, just pointing out that dropping Phoenix > > coprocessors compiled with Java 8 into a Java 7 runtime won't work. It is > > unclear at least to me if mixing HBase compiled with Java 7 and > > coprocessors compiled with Java 8 in a Java 8 runtime would be ok. > > > > Based on that I would say Phoenix, at least the coprocessor code, is > > constrained by the compatibility choices that HBase makes. > > > > That said I don't know of an obstacle to a build process on the Phoenix > > side that uses Java 7 to build coprocessors and Java 8 to build the PQS. > > Maybe someone on the Phoenix project has tried it? Or can try it? > > > > On Tue, Dec 4, 2018 at 4:33 PM Zach York <zyork.contribut...@gmail.com> > > wrote: > > > > > Isn't Phoenix's compatibility guarantees separate from HBase's? If > > Phoenix > > > only works with a Java8 environment, then couldn't Phoenix only support > > > Java8 environments in releases after the Java 8 Avatica issue without > > > requiring HBase's compatibility to drop support for Java7? > > > > > > While it's nice to have Phoenix and HBase compatibility guarantees > remain > > > in sync, I don't think that's a requirement for either project. > > > I do feel like dropping support for a java version in a minor release > is > > > very questionable as a Java upgrade isn't always trivial. > Unfortunately, > > > this is a by product of our long lived release lines. > > > > > > On Tue, Dec 4, 2018 at 4:21 PM Andrew Purtell <apurt...@apache.org> > > wrote: > > > > > > > We have the current compatibility promise that we will build with > Java > > 7 > > > so > > > > folks using a Java 7 JRE can consume and deploy them. > > > > > > > > If we will be assuming Java 8 runtimes predominate, then we can build > > > with > > > > Java 8. > > > > > > > > > > > > On Tue, Dec 4, 2018 at 4:15 PM Sean Busbey <bus...@apache.org> > wrote: > > > > > > > > > What about installing Phoenix coprocessors built with Java 8 into a > > > Java > > > > 8 > > > > > runtime that's running the currently built for jdk7 HBase? > Shouldn't > > > that > > > > > work fine? > > > > > > > > > > On Tue, Dec 4, 2018, 16:16 Andrew Purtell <apurt...@apache.org > > wrote: > > > > > > > > > > > I thought only the Avatica module aka PQS must be compiled using > > Java > > > > 8? > > > > > > Maybe you can script a Phoenix build that uses the Java 7 > compiler > > > for > > > > > the > > > > > > coprocessor modules and a Java 8 compiler only for the PQS? > > > > > > > > > > > > Otherwise, if all Phoenix modules including the coprocessor code > > are > > > > > > compiled with Java 8, then HBase must also be compiled with Java > 8. > > > If > > > > > you > > > > > > attempt to install Phoenix coprocessors compiled with Java 8 > into a > > > > Java > > > > > > 7 + HBase runtime then you will see fatal runtime errors related > to > > > > > linkage > > > > > > errors in the concurrent data types. > > > > > > > > > > > > > > > > > > On Tue, Dec 4, 2018 at 1:54 PM Josh Elser <els...@apache.org> > > wrote: > > > > > > > > > > > > > On 12/4/18 3:28 PM, Sean Busbey wrote: > > > > > > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <els...@apache.org > > > > > > wrote: > > > > > > > >> > > > > > > > >> Phoenix depends on Avatica for its Phoenix Query Server. > > Avatica > > > > > > > >> requires Java8. Thus, the impasse. > > > > > > > >> > > > > > > > > > > > > > > > > Generally our maintaining JDK7 support shouldn't limit the > > > ability > > > > of > > > > > > > > any downstream user to require a newer JDK. Is there some > > context > > > > I'm > > > > > > > > missing? Are they manually recompiling some part of our > > codebase > > > > that > > > > > > > > doesn't work with JDK8? Or do they not want to have folks > > > > complaining > > > > > > > > to them for requiring a JDK update that we don't require? > > > > > > > > > > > > > > Phoenix isn't doing anything exceptional. > > > > > > > > > > > > > > I'm struggling to find the Phoenix thread where Andrew P > > suggested > > > > that > > > > > > > I start this discussion in HBase. I don't remember if Phoenix > is > > > > using > > > > > > > JDK7 purely to build solely because HBase does, or if there is > a > > > > > > > technical reason that this is required. I'll have to keep > > looking. > > > > > > > > > > > > > > >> I'd pose the question: are we really doing our users a > service > > > for > > > > > > > >> continuing to allow them to use Java7? Not trying to be > > > > contentious > > > > > in > > > > > > > >> asking that -- I am just (happily) seeing fewer and fewer > > folks > > > > > still > > > > > > on > > > > > > > >> Java7. > > > > > > > > > > > > > > > > Yes. Making it so downstream folks don't have to worry about > > > > certain > > > > > > > > categories of changes is the entire advantage of us declaring > > > > > backward > > > > > > > > compatibility promises at all. JDK changes are a big deal in > > any > > > > > > > > deployment. > > > > > > > > > > > > > > > > As a project we already have a path forward for no longer > > > worrying > > > > > > > > about maintaining Java 7 support; it's Apache HBase 2+. > > Providing > > > > > > > > advantages for that move and reducing the risk of updating to > > it > > > > is a > > > > > > > > straight forward way to remove our limitation on JDK > features. > > > > IMHO, > > > > > > > > making it riskier to upgrade to newer 1.y minor versions is > an > > > > > > > > undesirable way to drive that change. > > > > > > > > > > > > > > I disagree with you on this point but that is fine. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
