Agreed, makes sense interested parties should help Matteo get 2.0 out this year. I'm on board.
On Fri, Sep 9, 2016 at 10:50 AM, Sean Busbey <bus...@apache.org> wrote: > This would be a very big breaking change in release numbering that goes > against our compatibility guidelines. We only drop support for Java > versions on major releases. > > If we want features that require newer jdks sooner, we should make major > releases sooner. > > On Sep 8, 2016 20:54, "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. > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
