You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Josh Elser <el...@apache.org> on 2018/12/04 20:14:24 UTC
Re: [DISCUSS] JDK8 for >=1.5.x?
Phoenix depends on Avatica for its Phoenix Query Server. Avatica
requires Java8. Thus, the impasse.
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.
On 11/30/18 4:55 PM, Sean Busbey wrote:
> I'm opposed if only because I don't like weakening our compatibility
> promises.
>
> What does Phoenix (or other downstream folks) lose out on because we work
> with jdk7 on our branch-1 releases?
>
> On Fri, Nov 30, 2018, 15:20 Josh Elser <elserj@apache.org wrote:
>
>> We came back across this in Phoenix recently and Andrew suggested we
>> talk about it here in HBase.
>>
>> Can/should we move to requiring Java8 for HBase 1.5 and beyond?
>>
>> It would have my vote.
>>
>> - Josh
>>
>
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Sean Busbey <bu...@apache.org>.
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 <tdsilva@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 <ap...@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 <zy...@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 <ap...@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 <bu...@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 <apurtell@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 <el...@apache.org>
> > wrote:
> > > > > >
> > > > > > > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > > > > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <elserj@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
> >
>
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Thomas D'Silva <td...@salesforce.com>.
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 <ap...@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 <zy...@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 <ap...@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 <bu...@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 <apurtell@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 <el...@apache.org>
> wrote:
> > > > >
> > > > > > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > > > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
>
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Andrew Purtell <ap...@apache.org>.
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 <zy...@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 <ap...@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 <bu...@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 <apurtell@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 <el...@apache.org> wrote:
> > > >
> > > > > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Zach York <zy...@gmail.com>.
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 <ap...@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 <bu...@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 <apurtell@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 <el...@apache.org> wrote:
> > >
> > > > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
>
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@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 <apurtell@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 <el...@apache.org> wrote:
> >
> > > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Sean Busbey <bu...@apache.org>.
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 <apurtell@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 <el...@apache.org> wrote:
>
> > On 12/4/18 3:28 PM, Sean Busbey wrote:
> > > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
>
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Andrew Purtell <ap...@apache.org>.
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 <el...@apache.org> wrote:
> On 12/4/18 3:28 PM, Sean Busbey wrote:
> > On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Josh Elser <el...@apache.org>.
On 12/4/18 3:28 PM, Sean Busbey wrote:
> On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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.
Re: [DISCUSS] JDK8 for >=1.5.x?
Posted by Sean Busbey <bu...@apache.org>.
On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <el...@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?
> 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.