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
