See http://hbase.apache.org/book.html#hbase.versioning. Dependency Compatibility, required for minor and patch releases, includes:
*An upgrade of HBase will not require an incompatible upgrade of the Java runtime.* If we compile HBase with Java 8 or up and then ship the binaries to a deployment environment based on a Java 7 JRE, then there are linkage errors in the java.util.concurrent package and HBase won't start. Our compatibility guidelines as stated require us to not break existing Java runtimes. For branch-1 and release branches derived from it we've stated the minimum JRE version is 7. So unfortunately until the end of life of branch-1 and any release branches derived from it the release managers must build binary convenience artifacts with 7u80, or a later compiler with -source 1.7 and boot classpath set to the 7u80 JRE libraries, effectively the same thing. Phoenix isn't necessarily subject to this limitation, however. T his is an issue for binary compatibility artifacts only. The HBase project will continue to provide them, but you can opt to stop distributing them. If you decide to stop building and distributing binaries, as long as your sources remain Java 7 compatible then whatever JDKs your contributors and committers utilize will be irrelevant. On Mon, Aug 6, 2018 at 3:39 PM Geoffrey Jacoby <[email protected]> wrote: > According to the HBase docs, all 1.x branches currently support JDK 7, > though HBase 2.0 supports only JDK 8. While I'd love to move up to JDK 8 on > the Phoenix side, I think we should wait until HBase takes a similar step > for branch-1, if they ever do. > > Geoffrey > > On Mon, Aug 6, 2018 at 3:20 PM, Karan Mehta <[email protected]> > wrote: > > > Hello all, > > > > Should we move these branches to 1.8 JDK? > > > > Karan > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
