hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Date Fri, 09 Sep 2016 17:57:38 GMT
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 <busbey@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" <zhangduo@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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message