Discussion:
[DISCUSS] JDK8 for >=1.5.x?
Josh Elser
2018-11-30 21:20:39 UTC
Permalink
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
Sean Busbey
2018-11-30 21:55:04 UTC
Permalink
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?
Post by Josh Elser
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
Josh Elser
2018-12-04 20:14:24 UTC
Permalink
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.
Post by Sean Busbey
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?
Post by Josh Elser
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
Sean Busbey
2018-12-04 20:28:16 UTC
Permalink
Post by Josh Elser
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?
Post by Josh Elser
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.
Josh Elser
2018-12-04 21:54:12 UTC
Permalink
Post by Sean Busbey
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
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.
Andrew Purtell
2018-12-04 22:15:22 UTC
Permalink
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.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
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
Sean Busbey
2018-12-05 00:15:32 UTC
Permalink
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?
Post by Andrew Purtell
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.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
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
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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
Andrew Purtell
2018-12-05 00:20:47 UTC
Permalink
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.
Post by Sean Busbey
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?
Post by Andrew Purtell
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
Post by Andrew Purtell
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
Post by Andrew Purtell
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
Post by Andrew Purtell
errors in the concurrent data types.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
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
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
asking that -- I am just (happily) seeing fewer and fewer folks
still
Post by Andrew Purtell
on
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Zach York
2018-12-05 00:32:57 UTC
Permalink
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.
Post by Andrew Purtell
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.
Post by Sean Busbey
What about installing Phoenix coprocessors built with Java 8 into a Java
8
Post by Sean Busbey
runtime that's running the currently built for jdk7 HBase? Shouldn't that
work fine?
Post by Andrew Purtell
I thought only the Avatica module aka PQS must be compiled using Java
8?
Post by Sean Busbey
Post by Andrew Purtell
Maybe you can script a Phoenix build that uses the Java 7 compiler for
the
Post by Andrew Purtell
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
Post by Andrew Purtell
attempt to install Phoenix coprocessors compiled with Java 8 into a
Java
Post by Sean Busbey
Post by Andrew Purtell
7 + HBase runtime then you will see fatal runtime errors related to
linkage
Post by Andrew Purtell
errors in the concurrent data types.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
any downstream user to require a newer JDK. Is there some context
I'm
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
missing? Are they manually recompiling some part of our codebase
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
doesn't work with JDK8? Or do they not want to have folks
complaining
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
I start this discussion in HBase. I don't remember if Phoenix is
using
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
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
Post by Sean Busbey
in
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
asking that -- I am just (happily) seeing fewer and fewer folks
still
Post by Andrew Purtell
on
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Java7.
Yes. Making it so downstream folks don't have to worry about
certain
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
categories of changes is the entire advantage of us declaring
backward
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
straight forward way to remove our limitation on JDK features.
IMHO,
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Andrew Purtell
2018-12-05 00:36:30 UTC
Permalink
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?
Post by Zach York
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.
Post by Andrew Purtell
We have the current compatibility promise that we will build with Java 7
so
Post by Andrew Purtell
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
Post by Andrew Purtell
Java 8.
Post by Sean Busbey
What about installing Phoenix coprocessors built with Java 8 into a
Java
Post by Andrew Purtell
8
Post by Sean Busbey
runtime that's running the currently built for jdk7 HBase? Shouldn't
that
Post by Andrew Purtell
Post by Sean Busbey
work fine?
Post by Andrew Purtell
I thought only the Avatica module aka PQS must be compiled using Java
8?
Post by Sean Busbey
Post by Andrew Purtell
Maybe you can script a Phoenix build that uses the Java 7 compiler
for
Post by Andrew Purtell
Post by Sean Busbey
the
Post by Andrew Purtell
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
Post by Andrew Purtell
Post by Sean Busbey
you
Post by Andrew Purtell
attempt to install Phoenix coprocessors compiled with Java 8 into a
Java
Post by Sean Busbey
Post by Andrew Purtell
7 + HBase runtime then you will see fatal runtime errors related to
linkage
Post by Andrew Purtell
errors in the concurrent data types.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
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
Post by Andrew Purtell
of
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
any downstream user to require a newer JDK. Is there some context
I'm
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
missing? Are they manually recompiling some part of our codebase
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
doesn't work with JDK8? Or do they not want to have folks
complaining
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
I start this discussion in HBase. I don't remember if Phoenix is
using
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
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.
Post by Sean Busbey
Post by Josh Elser
I'd pose the question: are we really doing our users a service
for
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
continuing to allow them to use Java7? Not trying to be
contentious
Post by Sean Busbey
in
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
asking that -- I am just (happily) seeing fewer and fewer folks
still
Post by Andrew Purtell
on
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Java7.
Yes. Making it so downstream folks don't have to worry about
certain
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
categories of changes is the entire advantage of us declaring
backward
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
straight forward way to remove our limitation on JDK features.
IMHO,
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
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
Thomas D'Silva
2018-12-05 01:05:34 UTC
Permalink
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.
Post by Andrew Purtell
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?
Post by Zach York
Isn't Phoenix's compatibility guarantees separate from HBase's? If
Phoenix
Post by Zach York
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.
Post by Andrew Purtell
We have the current compatibility promise that we will build with Java
7
Post by Zach York
so
Post by Andrew Purtell
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
Post by Andrew Purtell
Java 8.
Post by Sean Busbey
What about installing Phoenix coprocessors built with Java 8 into a
Java
Post by Andrew Purtell
8
Post by Sean Busbey
runtime that's running the currently built for jdk7 HBase? Shouldn't
that
Post by Andrew Purtell
Post by Sean Busbey
work fine?
Post by Andrew Purtell
I thought only the Avatica module aka PQS must be compiled using
Java
Post by Zach York
Post by Andrew Purtell
8?
Post by Sean Busbey
Post by Andrew Purtell
Maybe you can script a Phoenix build that uses the Java 7 compiler
for
Post by Andrew Purtell
Post by Sean Busbey
the
Post by Andrew Purtell
coprocessor modules and a Java 8 compiler only for the PQS?
Otherwise, if all Phoenix modules including the coprocessor code
are
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
compiled with Java 8, then HBase must also be compiled with Java 8.
If
Post by Andrew Purtell
Post by Sean Busbey
you
Post by Andrew Purtell
attempt to install Phoenix coprocessors compiled with Java 8 into a
Java
Post by Sean Busbey
Post by Andrew Purtell
7 + HBase runtime then you will see fatal runtime errors related to
linkage
Post by Andrew Purtell
errors in the concurrent data types.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Phoenix depends on Avatica for its Phoenix Query Server.
Avatica
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
requires Java8. Thus, the impasse.
Generally our maintaining JDK7 support shouldn't limit the
ability
Post by Andrew Purtell
of
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
any downstream user to require a newer JDK. Is there some
context
Post by Zach York
Post by Andrew Purtell
I'm
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
missing? Are they manually recompiling some part of our
codebase
Post by Zach York
Post by Andrew Purtell
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
doesn't work with JDK8? Or do they not want to have folks
complaining
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Zach York
Post by Andrew Purtell
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
I start this discussion in HBase. I don't remember if Phoenix is
using
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
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.
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
I'd pose the question: are we really doing our users a service
for
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
continuing to allow them to use Java7? Not trying to be
contentious
Post by Sean Busbey
in
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
asking that -- I am just (happily) seeing fewer and fewer
folks
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
still
Post by Andrew Purtell
on
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Java7.
Yes. Making it so downstream folks don't have to worry about
certain
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
categories of changes is the entire advantage of us declaring
backward
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
compatibility promises at all. JDK changes are a big deal in
any
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
deployment.
As a project we already have a path forward for no longer
worrying
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
about maintaining Java 7 support; it's Apache HBase 2+.
Providing
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
advantages for that move and reducing the risk of updating to
it
Post by Zach York
Post by Andrew Purtell
is a
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
straight forward way to remove our limitation on JDK features.
IMHO,
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
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
Sean Busbey
2018-12-05 01:28:55 UTC
Permalink
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.
Post by Thomas D'Silva
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.
Post by Andrew Purtell
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?
Post by Zach York
Isn't Phoenix's compatibility guarantees separate from HBase's? If
Phoenix
Post by Zach York
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
Post by Andrew Purtell
Post by Zach York
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
Post by Andrew Purtell
Post by Zach York
very questionable as a Java upgrade isn't always trivial.
Unfortunately,
Post by Andrew Purtell
Post by Zach York
this is a by product of our long lived release lines.
Post by Andrew Purtell
We have the current compatibility promise that we will build with
Java
Post by Andrew Purtell
7
Post by Zach York
so
Post by Andrew Purtell
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
Post by Andrew Purtell
Java 8.
Post by Sean Busbey
What about installing Phoenix coprocessors built with Java 8 into a
Java
Post by Andrew Purtell
8
Post by Sean Busbey
runtime that's running the currently built for jdk7 HBase?
Shouldn't
Post by Andrew Purtell
Post by Zach York
that
Post by Andrew Purtell
Post by Sean Busbey
work fine?
Post by Andrew Purtell
I thought only the Avatica module aka PQS must be compiled using
Java
Post by Zach York
Post by Andrew Purtell
8?
Post by Sean Busbey
Post by Andrew Purtell
Maybe you can script a Phoenix build that uses the Java 7
compiler
Post by Andrew Purtell
Post by Zach York
for
Post by Andrew Purtell
Post by Sean Busbey
the
Post by Andrew Purtell
coprocessor modules and a Java 8 compiler only for the PQS?
Otherwise, if all Phoenix modules including the coprocessor code
are
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
compiled with Java 8, then HBase must also be compiled with Java
8.
Post by Andrew Purtell
Post by Zach York
If
Post by Andrew Purtell
Post by Sean Busbey
you
Post by Andrew Purtell
attempt to install Phoenix coprocessors compiled with Java 8
into a
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
Java
Post by Sean Busbey
Post by Andrew Purtell
7 + HBase runtime then you will see fatal runtime errors related
to
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
linkage
Post by Andrew Purtell
errors in the concurrent data types.
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Phoenix depends on Avatica for its Phoenix Query Server.
Avatica
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
requires Java8. Thus, the impasse.
Generally our maintaining JDK7 support shouldn't limit the
ability
Post by Andrew Purtell
of
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
any downstream user to require a newer JDK. Is there some
context
Post by Zach York
Post by Andrew Purtell
I'm
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
missing? Are they manually recompiling some part of our
codebase
Post by Zach York
Post by Andrew Purtell
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
doesn't work with JDK8? Or do they not want to have folks
complaining
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Zach York
Post by Andrew Purtell
that
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
I start this discussion in HBase. I don't remember if Phoenix
is
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
using
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
JDK7 purely to build solely because HBase does, or if there is
a
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
technical reason that this is required. I'll have to keep
looking.
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
I'd pose the question: are we really doing our users a
service
Post by Andrew Purtell
Post by Zach York
for
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
continuing to allow them to use Java7? Not trying to be
contentious
Post by Sean Busbey
in
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
asking that -- I am just (happily) seeing fewer and fewer
folks
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
still
Post by Andrew Purtell
on
Post by Josh Elser
Post by Sean Busbey
Post by Josh Elser
Java7.
Yes. Making it so downstream folks don't have to worry about
certain
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
categories of changes is the entire advantage of us declaring
backward
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
compatibility promises at all. JDK changes are a big deal in
any
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
deployment.
As a project we already have a path forward for no longer
worrying
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
about maintaining Java 7 support; it's Apache HBase 2+.
Providing
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
advantages for that move and reducing the risk of updating to
it
Post by Zach York
Post by Andrew Purtell
is a
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
straight forward way to remove our limitation on JDK
features.
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
IMHO,
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
making it riskier to upgrade to newer 1.y minor versions is
an
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
Post by Josh Elser
Post by Sean Busbey
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
Post by Andrew Purtell
Post by Sean Busbey
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by Andrew Purtell
Post by Zach York
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Loading...