hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Date Fri, 09 Sep 2016 04:33:26 GMT
Our compatibility guidelines do not allow dropping support for a Java version in a minor or
patch release by introducing code that won't link with the older runtime: http://hbase.apache.org/book.html#hbase.versioning

See the Dependency Compatibility section in particular. 

An upgrade of HBase will not require an incompatible upgrade of a dependent project, including
the Java runtime.

> On Sep 8, 2016, at 9:19 PM, 张铎 <palomino219@gmail.com> wrote:
> So all the asynchronous api will be introduced in 2.0 only?
> And java7 has been end of life for more than one year...
> And also, for a upgrade, I do not think it is a good idea to upgrade JDK
> and HBase together. So you always need to upgrade to jdk8 or later first at
> some time before upgrading to a jdk8 only HBase version, no matter you want
> to upgrade to 2.0 or 1.4, this does not change.
> 2016-09-09 12:01 GMT+08:00 Ted Yu <yuzhihong@gmail.com>:
>> Yeah, we should keep support for Java 7 in branch-1.
>> We can use CompletableFuture for 2.0 release.
>> On Thu, Sep 8, 2016 at 8:56 PM, Andrew Purtell <andrew.purtell@gmail.com>
>> wrote:
>>> I think we should wait until 2.0 before dropping support for less than
>> JDK
>>> 8. That's a pretty big deal. But, for 2.0, that would be fine IMHO.
>>>> On Sep 8, 2016, at 8:54 PM, 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.

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message