Hi folks! Our ref guide section on Java versions[1] is starting to look dated, because the Oracle version of Java 9 hits end of public updates this month and we don't mention it at all.
I'd like to discuss how we want to approach keeping HBase up-to-date on new Java versions. As background, the Java community is moving to a time-based release schedule where there is a new long term support (LTS) version every ~three years[2]. Between those, there are a series of feature releases that only have a short window of receiving updates. -- "Recommended" for running I think we should suggest folks rely on LTS releases of Java, wether from the OpenJDK project (which looks like it will be equivalent to the Oracle version) or a vender. That would mean updating our support matrix to call out Java 9 and Java 10 as "Not Supported" for current releases. -- Development changes The next LTS version of Java is slated to be Java 11, which won't be out until September 2018. I think we should aim for a minor release on whatever major branches are still active within a month of the GA date where we feel comfortable calling out Java 11 as supported. To that end, I think we would should do 2 things: 1) Work to make sure we can run through our test suite with either the release prior to the next LTS or an early access version of the upcoming LTS release before the GA date, ideally ~3 months before. That'd be a target of June 2018 for the planned GA date of Java 11. I expect that means abandoning our Java 9 specific efforts and starting in April/May to work on updates related to Java 10 (or 11 depending on when bits start shipping). 2) In the process of getting the above to work if we find we can't get a major release branch ready to go without violating our compatibility guidelines (especially wrt the existing supported java versions), we should cease making new minor releases for that major release branch. This could mean either just going to bugfix releases or it could mean declaring the branch EOM entirely. Note that the above doesn't necessarily require that we be able to build with a newer JDK version. That would certainly be simpler though; I don't think our current tooling makes it easy to run tests with a different JDK than is used to compile. -- Dropping of older versions I don't think we've codified anywhere when we drop Java version supports? (our guide merely says when we _could_.) I'm also not sure if we should write it down somewhere? If we can stick to the above and proactively add new versions as supported in minor releases, I think we'll be in a good position to drop everything but the latest LTS Java release with each HBase major release. Since this notion of LTS and non-LTS releases for Java is still relatively new, maybe that's a discussion we're better off having once HBase 3 is closer. [1]: http://hbase.apache.org/book.html#java [2]: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
