phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankit Singhal <>
Subject Re: Are we embracing Java 8?
Date Thu, 23 Apr 2020 03:11:19 GMT
Just linking a discussion we had one and a half years back on the same [1],
considering nothing has changed since then because Java 7 was EOLed in July
and Phoenix 5.0 was also out, it majorly comes to the point of the
inconvenience of working
on old code style and extra efforts required to create patches for each

Let's say if we decide to upgrade to Java8(Option 3), don't we require the
following changes?

* Major version upgrade from 4.x-HBase-1.x to 5.x-HBase-1.x:- As upgrading
4.x branches
to Java8 breaks the compatibility with HBase and Java runtime, we need to
ensure that
we adhere to dependency compatibility between the minor releases as it is
expected that
Phoenix minor upgrade should be just a server jar drop and a restart (even
we don't explicit covers Java runtime in our backward compatibility [2] as
HBase does[3]
but people are used to it now)

* Release Notes and convenience libraries:- Though we would say that it is
compatible with
HBase version 1.x but require a Java8, so we need to be explicit with our
convenience libraries
as well , like append "jdk8" to a name or something similar
And also provide clarity on the version upgrade

* Avoiding issues during runtime:- Though JAVA8 and JAVA7 are said to be
binary compatible
and are expected to be fine in Java8 runtime but it has been called out
there are rare instances
which can cause issues due to some incompatibilities between JRE and
JDK[4]. (As Andrew also
called out and might have observed the same)

Though I agreed with Istvan that creating multiple patches and dealing with
change in code style every time
we switch branches has put additional load on the contributor but IMHO, we
should wait for
HBase-1.x to upgrade Java before we do it to avoid the some of the issues
listed above related to Option 3.

Option2 would be preferred at the time when we decide on whether we want to
diverge from feature
parity in our major releases and we do only limited fixes for 4.x branch.
So basically I'm also in favor of Option 1 (continuing Java 7 for HBase-1.x
and code style as much possible for 5.x).


Ankit Singhal

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message