> -- "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. >
+1 for at least calling out Java 9 and Java 10 as "Not Tested" (Not Supported if we know for sure it won't work). As for recommending folks rely on LTS releases, I think this will require a shift in thinking from most people in the Hadoop ecosystem to upgrade the Java versions more frequently. Otherwise it will become a pain for users to use multiple open source projects in the same environment (for example if Hadoop is using Java 8, Spark - Java 9, and HBase - Java 11). Not saying that we should hold ourselves back because of other projects, but we should at least consider the burden. I do, however, think that long term we should only recommend running with the current LTS release. Getting there might be a lot of fun though :) > > -- 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). > > +1, doesn't make sense doing work that will be already be obsolete by this desired direction. > 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. > I don't see this happening before 3.0 anyways. Let's work on getting 1) done for Java 9/10. I think we should wait until we see how this is all going to pan out (and how much work each upgrade will be) before making anything public, but I think this is a good goal. Thanks for writing this up, Zach
