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 >
