For a company upgrade JDK to 8 will change many things. So if we drop the support for less than JDK 8 at 1.4, then It is probable that people neither upgrade JDK to 8 nor upgrade HBase to 1.4. And they will use JDK 7 + HBase 1.3 for a long time. But actually upgrade JDK to 8 is not a big deal. They are just scaring.
2016-09-08 21:01 GMT-07:00 Dima Spivak <dimaspi...@apache.org>: > I'd worry about doing this from both the client-server compatibility side > as well as for when it comes to upgrades. Having to go between Java > versions is way scarier for ops people than just swapping JARs. > > On Thursday, September 8, 2016, Duo Zhang <zhang...@apache.org> wrote: > > > The main reason is the asynchronous api we want to introduce in HBase > > today. See HBASE-13784 and HBASE-16505. > > > > The CompletableFuture in java8 is very suitable to use as the return > value > > of a async method. We can not use it if we still want to support java7, > and > > sadly, there is no candidate which is good enough to replace > > CompletableFuture. ListenableFuture in guava or Promise in netty are > good, > > but we do not want to expose third-party classes in our public > > API(especially guava, you know...). And we can also implement our own > > ListenableFuture but it just a copy of guava. Or introduce a simple > > Callback interface which does not need much code(for us) but this is a > code > > style around 2000s so people will not like it... > > > > And luckily, I found that in our documentation > > > > http://hbase.apache.org/book.html#basic.prerequisites > > > > We only say that 1.3 will be compatible with jdk7, not all 1.x. > > > > So here I propose that we drop the support of jdk7 in a future 1.x > release, > > maybe 1.4? Thus we can use CompletableFuture in both master and branch-1. > > > > Thanks. > > > > > -- > -Dima >
