Sorry to slightly digress, but based on these discussions, shouldn't we be setting JAVA_HOME to point to JDK 7 in all our builds? Especially based on Andrew's comment above: "
*Java 7 is not forwards compatible with Java 8, especially with respect toJRE internals. What that means is if you compile something with Java 8,even if you are not using Java 8 language features, you won't be able torun it on a Java 7 runtime.*" Our 4.x build <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure> is configured with java 1.8: [image: 4.x.png] In our master build <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/configure>, we don't even specify JAVA_HOME, so essentially it picks up the latest version. Precommit gets JAVA_HOME set from $PHOENIX/dev/jenkensEnv.sh. There have been issues where master builds failed because they used JDK 11 ( https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/71/consoleFull), search for "JAVA VERSION" in the log file. The same build does not fail if run with JDK 8. Also, doesn't this mean we are already compiling with Java 8 (at least in the 4.x branches) or am I missing something? <https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-4.x-matrix/configure> On Wed, Apr 22, 2020 at 8:11 PM Ankit Singhal <ankitsingha...@gmail.com> wrote: > 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 > 2015 > 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 > branch. > > 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 > though > 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 > (phoenix-server-HBase-1.x-jdk8.jar). > 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). > > [1] > > https://lists.apache.org/thread.html/970db0b5cb0560c49654e450aafb8fb759596384cefe4f02808e80cc%40%3Cdev.phoenix.apache.org%3E > [2]http://phoenix.apache.org/upgrading.html > [3] https://hbase.apache.org/book.html#hbase.versioning > [4] > > https://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387 > > Regards, > Ankit Singhal > -- Chinmay Kulkarni
