You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Duo Zhang <zh...@apache.org> on 2016/09/09 03:54:14 UTC
[DISCUSS] Drop the support of jdk7 at a future 1.x release
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.
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by 张铎 <pa...@gmail.com>.
Yeah I'm currently working on HBASE-16591 to bring our master build
pipeline to jdk8 only...
2016-09-10 2:11 GMT+08:00 Josh Elser <el...@apache.org>:
>
>
> Sean Busbey 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.
>>
>
> +1 On this exactly
>
>
> On Sep 8, 2016 20:54, "Duo Zhang"<zh...@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.
>>>
>>>
>>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by 张铎 <pa...@gmail.com>.
Yeah I'm currently working on HBASE-16591 to bring our master build
pipeline to jdk8 only...
2016-09-10 2:11 GMT+08:00 Josh Elser <el...@apache.org>:
>
>
> Sean Busbey 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.
>>
>
> +1 On this exactly
>
>
> On Sep 8, 2016 20:54, "Duo Zhang"<zh...@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.
>>>
>>>
>>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Josh Elser <el...@apache.org>.
Sean Busbey 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.
+1 On this exactly
> On Sep 8, 2016 20:54, "Duo Zhang"<zh...@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.
>>
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Josh Elser <el...@apache.org>.
Sean Busbey 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.
+1 On this exactly
> On Sep 8, 2016 20:54, "Duo Zhang"<zh...@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.
>>
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@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" <zh...@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)
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@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" <zh...@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)
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Sean Busbey <bu...@apache.org>.
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" <zh...@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.
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by 张铎 <pa...@gmail.com>.
OK, I know. Thanks.
The layout of the table is broken so I misunderstood the meaning... I
thought the last five line in the table is only used to describe the
Server-Side Limited API...
2016年9月9日星期五，Andrew Purtell <an...@gmail.com> 写道：
> 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, 张铎 <pa...@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 <yu...@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 <zh...@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.
> >>
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Andrew Purtell <an...@gmail.com>.
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, 张铎 <pa...@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 <yu...@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 <an...@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 <zh...@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.
>>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by 张铎 <pa...@gmail.com>.
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 <yu...@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 <an...@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 <zh...@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.
> >
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Ted Yu <yu...@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 <an...@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 <zh...@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.
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Andrew Purtell <an...@gmail.com>.
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 <zh...@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.
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Andrew Purtell <an...@gmail.com>.
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 <zh...@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.
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Sean Busbey <bu...@apache.org>.
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" <zh...@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.
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Xi Yang <al...@gmail.com>.
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 <di...@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 <zh...@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
>
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Dima Spivak <di...@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 <zh...@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
Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release
Posted by Dima Spivak <di...@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 <zh...@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