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
