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
