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 2017/03/16 05:28:49 UTC
About adding methods to an interface which is part of our public API
in minor release
There are some comments in https://issues.apache.org/jira/browse/HBASE-17584
.
In HBASE-17584, we want to remove Scan.getScanMetrics and move the method
to ResultScanner which is an interface and part of our public API.
In our refguide, it is clear that we can do this for a major release.
And for patch release, it is also clear that we are not allowed to do this.
New APIs introduced in a patch version will only be added in a source
compatible way [1 <http://hbase.apache.org/book.html#_footnote_1>]: i.e.
code that implements public APIs will continue to compile.
But for minor release, it is a liitle inexplicit.
A minor upgrade requires no application/client code modification. Ideally
it would be a drop-in replacement but client code, coprocessors, filters,
etc might have to be recompiled if new jars are used.
If no client code modification is required, then we are not allowed to add
methods to interface as it will cause compliation error if user extends the
interface as on branch-1, we still need to support JDK7 which does not
support default method. But I think this will make minor release almost the
same with patch release? And another point is that, for most users, they
only use the interface and do not implement it, so adding methods will not
break their code.
So here we want to see what the community think of whether we should allow
adding methods to interface in minor release. Any comments are welcomed.
Thanks.
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Enis Söztutar <en...@apache.org>.
+1 for the wording in the book. Otherwise, we cannot add methods to Table /
Admin in a minor release, which is very restricting.
> How about the idea of HBase having base implementations for common
interfaces
This is only needed in JDK-7, so basically in 1.x releases. With Java-8, we
are doing default methods in interfaces instead.
Enis
On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org> wrote:
> +1 to the JDK8 default implementation approach. I'd say this would be good
> to push forward for the future.
>
> For 1.x, I see no reason why we couldn't provide concrete implementations
> as a stop-gap. Identifying and creating those classes is probably the
> biggest barrier :). I don't think anything really stops us from doing this
> now...
>
>
> James Taylor wrote:
>
>> How about the idea of HBase having base implementations for common
>> interfaces? That would often help applications built on top of HBase to
>> maintain backward compatibility from release to release.
>>
>> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
>>
>> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org> wrote:
>>>
>>> There are some comments in https://issues.apache.org/
>>>> jira/browse/HBASE-17584
>>>> .
>>>>
>>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
>>>> method
>>>> to ResultScanner which is an interface and part of our public API.
>>>>
>>>> In our refguide, it is clear that we can do this for a major release.
>>>> And for patch release, it is also clear that we are not allowed to do
>>>>
>>> this.
>>>
>>>> New APIs introduced in a patch version will only be added in a source
>>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]: i.e.
>>>> code that implements public APIs will continue to compile.
>>>>
>>>>
>>>> But for minor release, it is a liitle inexplicit.
>>>>
>>>> A minor upgrade requires no application/client code modification.
>>>> Ideally
>>>> it would be a drop-in replacement but client code, coprocessors,
>>>> filters,
>>>> etc might have to be recompiled if new jars are used.
>>>>
>>>> If no client code modification is required, then we are not allowed to
>>>>
>>> add
>>>
>>>> methods to interface as it will cause compliation error if user extends
>>>>
>>> the
>>>
>>>> interface as on branch-1, we still need to support JDK7 which does not
>>>> support default method. But I think this will make minor release almost
>>>>
>>> the
>>>
>>>> same with patch release? And another point is that, for most users, they
>>>> only use the interface and do not implement it, so adding methods will
>>>>
>>> not
>>>
>>>> break their code.
>>>>
>>>> So here we want to see what the community think of whether we should
>>>>
>>> allow
>>>
>>>> adding methods to interface in minor release. Any comments are welcomed.
>>>>
>>>>
>>>> I'd suggest we add to the refguide a clarification that allows addition
>>> of
>>> new methods to Interfaces in minor releases. Here is a suggested
>>> addition:
>>>
>>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have
>>> to
>>> recompile. We reserve the right to add new methods to existing Interfaces
>>> on minor updates (this will be less of an issue in hbase-2.0.0 which
>>> requires JDK8; JDK8 allows specification of 'default' implementations of
>>> Interface methods)"
>>>
>>> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
>>>
>>> St.Ack
>>>
>>>
>>>
>>> Thanks.
>>>>
>>>>
>>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Ted Yu <yu...@gmail.com>.
+1 to what Josh and James said.
On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org> wrote:
> +1 to the JDK8 default implementation approach. I'd say this would be good
> to push forward for the future.
>
> For 1.x, I see no reason why we couldn't provide concrete implementations
> as a stop-gap. Identifying and creating those classes is probably the
> biggest barrier :). I don't think anything really stops us from doing this
> now...
>
> James Taylor wrote:
>
>> How about the idea of HBase having base implementations for common
>> interfaces? That would often help applications built on top of HBase to
>> maintain backward compatibility from release to release.
>>
>> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
>>
>> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org> wrote:
>>>
>>> There are some comments in https://issues.apache.org/
>>>> jira/browse/HBASE-17584
>>>> .
>>>>
>>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
>>>> method
>>>> to ResultScanner which is an interface and part of our public API.
>>>>
>>>> In our refguide, it is clear that we can do this for a major release.
>>>> And for patch release, it is also clear that we are not allowed to do
>>>>
>>> this.
>>>
>>>> New APIs introduced in a patch version will only be added in a source
>>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]: i.e.
>>>> code that implements public APIs will continue to compile.
>>>>
>>>>
>>>> But for minor release, it is a liitle inexplicit.
>>>>
>>>> A minor upgrade requires no application/client code modification.
>>>> Ideally
>>>> it would be a drop-in replacement but client code, coprocessors,
>>>> filters,
>>>> etc might have to be recompiled if new jars are used.
>>>>
>>>> If no client code modification is required, then we are not allowed to
>>>>
>>> add
>>>
>>>> methods to interface as it will cause compliation error if user extends
>>>>
>>> the
>>>
>>>> interface as on branch-1, we still need to support JDK7 which does not
>>>> support default method. But I think this will make minor release almost
>>>>
>>> the
>>>
>>>> same with patch release? And another point is that, for most users, they
>>>> only use the interface and do not implement it, so adding methods will
>>>>
>>> not
>>>
>>>> break their code.
>>>>
>>>> So here we want to see what the community think of whether we should
>>>>
>>> allow
>>>
>>>> adding methods to interface in minor release. Any comments are welcomed.
>>>>
>>>>
>>>> I'd suggest we add to the refguide a clarification that allows addition
>>> of
>>> new methods to Interfaces in minor releases. Here is a suggested
>>> addition:
>>>
>>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have
>>> to
>>> recompile. We reserve the right to add new methods to existing Interfaces
>>> on minor updates (this will be less of an issue in hbase-2.0.0 which
>>> requires JDK8; JDK8 allows specification of 'default' implementations of
>>> Interface methods)"
>>>
>>> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
>>>
>>> St.Ack
>>>
>>>
>>>
>>> Thanks.
>>>>
>>>>
>>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Stack <st...@duboce.net>.
I added a proposed wording for refguide in client binary compat section in
refguide [1]
Issue is HBASE-17802. +1 if you good w/ it (or improvements also welcome).
Thanks,
St.Ack
1.
https://issues.apache.org/jira/secure/attachment/12859376/HBASE-17802.master.001.patch
On Thu, Mar 16, 2017 at 10:32 PM, Yu Li <ca...@gmail.com> wrote:
> +1 on allow adding methods to interfaces in minor release, especially
> before 2.0 is out, I don't think a minor release is that "minor" (smile).
>
> Regarding refguide, shall we also remind user to check the "incompatible"
> changes in release note before upgrading for minor version?
>
> Best Regards,
> Yu
>
> On 17 March 2017 at 08:50, Andrew Purtell <ap...@apache.org> wrote:
>
> > This sounds like a good result to me.
> > We've sometimes provided BaseXXX implementations of interfaces for Java
> <=
> > 7 but haven't been consistent. Would be good to do better.
> >
> > On Thu, Mar 16, 2017 at 2:18 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org>
> wrote:
> > >
> > > > +1 to the JDK8 default implementation approach. I'd say this would be
> > > good
> > > > to push forward for the future.
> > > >
> > > > For 1.x, I see no reason why we couldn't provide concrete
> > implementations
> > > > as a stop-gap. Identifying and creating those classes is probably the
> > > > biggest barrier :). I don't think anything really stops us from doing
> > > this
> > > > now...
> > > >
> > > >
> > > I can change the wording to say we will make a best effort at
> providing a
> > > default implementation but allow that it may not be always possible.
> > >
> > > St.Ack
> > >
> > >
> > >
> > >
> > > >
> > > > James Taylor wrote:
> > > >
> > > >> How about the idea of HBase having base implementations for common
> > > >> interfaces? That would often help applications built on top of HBase
> > to
> > > >> maintain backward compatibility from release to release.
> > > >>
> > > >> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
> > > >>
> > > >> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org>
> > > wrote:
> > > >>>
> > > >>> There are some comments in https://issues.apache.org/
> > > >>>> jira/browse/HBASE-17584
> > > >>>> .
> > > >>>>
> > > >>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
> > > >>>> method
> > > >>>> to ResultScanner which is an interface and part of our public
> API.
> > > >>>>
> > > >>>> In our refguide, it is clear that we can do this for a major
> > release.
> > > >>>> And for patch release, it is also clear that we are not allowed to
> > do
> > > >>>>
> > > >>> this.
> > > >>>
> > > >>>> New APIs introduced in a patch version will only be added in a
> > source
> > > >>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1
> >]:
> > > i.e.
> > > >>>> code that implements public APIs will continue to compile.
> > > >>>>
> > > >>>>
> > > >>>> But for minor release, it is a liitle inexplicit.
> > > >>>>
> > > >>>> A minor upgrade requires no application/client code modification.
> > > >>>> Ideally
> > > >>>> it would be a drop-in replacement but client code, coprocessors,
> > > >>>> filters,
> > > >>>> etc might have to be recompiled if new jars are used.
> > > >>>>
> > > >>>> If no client code modification is required, then we are not
> allowed
> > to
> > > >>>>
> > > >>> add
> > > >>>
> > > >>>> methods to interface as it will cause compliation error if user
> > > extends
> > > >>>>
> > > >>> the
> > > >>>
> > > >>>> interface as on branch-1, we still need to support JDK7 which does
> > not
> > > >>>> support default method. But I think this will make minor release
> > > almost
> > > >>>>
> > > >>> the
> > > >>>
> > > >>>> same with patch release? And another point is that, for most
> users,
> > > they
> > > >>>> only use the interface and do not implement it, so adding methods
> > will
> > > >>>>
> > > >>> not
> > > >>>
> > > >>>> break their code.
> > > >>>>
> > > >>>> So here we want to see what the community think of whether we
> should
> > > >>>>
> > > >>> allow
> > > >>>
> > > >>>> adding methods to interface in minor release. Any comments are
> > > welcomed.
> > > >>>>
> > > >>>>
> > > >>>> I'd suggest we add to the refguide a clarification that allows
> > > addition
> > > >>> of
> > > >>> new methods to Interfaces in minor releases. Here is a suggested
> > > >>> addition:
> > > >>>
> > > >>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may
> > > have
> > > >>> to
> > > >>> recompile. We reserve the right to add new methods to existing
> > > Interfaces
> > > >>> on minor updates (this will be less of an issue in hbase-2.0.0
> which
> > > >>> requires JDK8; JDK8 allows specification of 'default'
> implementations
> > > of
> > > >>> Interface methods)"
> > > >>>
> > > >>> I could add a further qualifier only applies to hbase-1.4.0 and
> > beyond?
> > > >>>
> > > >>> St.Ack
> > > >>>
> > > >>>
> > > >>>
> > > >>> Thanks.
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Yu Li <ca...@gmail.com>.
+1 on allow adding methods to interfaces in minor release, especially
before 2.0 is out, I don't think a minor release is that "minor" (smile).
Regarding refguide, shall we also remind user to check the "incompatible"
changes in release note before upgrading for minor version?
Best Regards,
Yu
On 17 March 2017 at 08:50, Andrew Purtell <ap...@apache.org> wrote:
> This sounds like a good result to me.
> We've sometimes provided BaseXXX implementations of interfaces for Java <=
> 7 but haven't been consistent. Would be good to do better.
>
> On Thu, Mar 16, 2017 at 2:18 PM, Stack <st...@duboce.net> wrote:
>
> > On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org> wrote:
> >
> > > +1 to the JDK8 default implementation approach. I'd say this would be
> > good
> > > to push forward for the future.
> > >
> > > For 1.x, I see no reason why we couldn't provide concrete
> implementations
> > > as a stop-gap. Identifying and creating those classes is probably the
> > > biggest barrier :). I don't think anything really stops us from doing
> > this
> > > now...
> > >
> > >
> > I can change the wording to say we will make a best effort at providing a
> > default implementation but allow that it may not be always possible.
> >
> > St.Ack
> >
> >
> >
> >
> > >
> > > James Taylor wrote:
> > >
> > >> How about the idea of HBase having base implementations for common
> > >> interfaces? That would often help applications built on top of HBase
> to
> > >> maintain backward compatibility from release to release.
> > >>
> > >> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
> > >>
> > >> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org>
> > wrote:
> > >>>
> > >>> There are some comments in https://issues.apache.org/
> > >>>> jira/browse/HBASE-17584
> > >>>> .
> > >>>>
> > >>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
> > >>>> method
> > >>>> to ResultScanner which is an interface and part of our public API.
> > >>>>
> > >>>> In our refguide, it is clear that we can do this for a major
> release.
> > >>>> And for patch release, it is also clear that we are not allowed to
> do
> > >>>>
> > >>> this.
> > >>>
> > >>>> New APIs introduced in a patch version will only be added in a
> source
> > >>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]:
> > i.e.
> > >>>> code that implements public APIs will continue to compile.
> > >>>>
> > >>>>
> > >>>> But for minor release, it is a liitle inexplicit.
> > >>>>
> > >>>> A minor upgrade requires no application/client code modification.
> > >>>> Ideally
> > >>>> it would be a drop-in replacement but client code, coprocessors,
> > >>>> filters,
> > >>>> etc might have to be recompiled if new jars are used.
> > >>>>
> > >>>> If no client code modification is required, then we are not allowed
> to
> > >>>>
> > >>> add
> > >>>
> > >>>> methods to interface as it will cause compliation error if user
> > extends
> > >>>>
> > >>> the
> > >>>
> > >>>> interface as on branch-1, we still need to support JDK7 which does
> not
> > >>>> support default method. But I think this will make minor release
> > almost
> > >>>>
> > >>> the
> > >>>
> > >>>> same with patch release? And another point is that, for most users,
> > they
> > >>>> only use the interface and do not implement it, so adding methods
> will
> > >>>>
> > >>> not
> > >>>
> > >>>> break their code.
> > >>>>
> > >>>> So here we want to see what the community think of whether we should
> > >>>>
> > >>> allow
> > >>>
> > >>>> adding methods to interface in minor release. Any comments are
> > welcomed.
> > >>>>
> > >>>>
> > >>>> I'd suggest we add to the refguide a clarification that allows
> > addition
> > >>> of
> > >>> new methods to Interfaces in minor releases. Here is a suggested
> > >>> addition:
> > >>>
> > >>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may
> > have
> > >>> to
> > >>> recompile. We reserve the right to add new methods to existing
> > Interfaces
> > >>> on minor updates (this will be less of an issue in hbase-2.0.0 which
> > >>> requires JDK8; JDK8 allows specification of 'default' implementations
> > of
> > >>> Interface methods)"
> > >>>
> > >>> I could add a further qualifier only applies to hbase-1.4.0 and
> beyond?
> > >>>
> > >>> St.Ack
> > >>>
> > >>>
> > >>>
> > >>> Thanks.
> > >>>>
> > >>>>
> > >>
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Andrew Purtell <ap...@apache.org>.
This sounds like a good result to me.
We've sometimes provided BaseXXX implementations of interfaces for Java <=
7 but haven't been consistent. Would be good to do better.
On Thu, Mar 16, 2017 at 2:18 PM, Stack <st...@duboce.net> wrote:
> On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org> wrote:
>
> > +1 to the JDK8 default implementation approach. I'd say this would be
> good
> > to push forward for the future.
> >
> > For 1.x, I see no reason why we couldn't provide concrete implementations
> > as a stop-gap. Identifying and creating those classes is probably the
> > biggest barrier :). I don't think anything really stops us from doing
> this
> > now...
> >
> >
> I can change the wording to say we will make a best effort at providing a
> default implementation but allow that it may not be always possible.
>
> St.Ack
>
>
>
>
> >
> > James Taylor wrote:
> >
> >> How about the idea of HBase having base implementations for common
> >> interfaces? That would often help applications built on top of HBase to
> >> maintain backward compatibility from release to release.
> >>
> >> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
> >>
> >> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org>
> wrote:
> >>>
> >>> There are some comments in https://issues.apache.org/
> >>>> jira/browse/HBASE-17584
> >>>> .
> >>>>
> >>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
> >>>> method
> >>>> to ResultScanner which is an interface and part of our public API.
> >>>>
> >>>> In our refguide, it is clear that we can do this for a major release.
> >>>> And for patch release, it is also clear that we are not allowed to do
> >>>>
> >>> this.
> >>>
> >>>> New APIs introduced in a patch version will only be added in a source
> >>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]:
> i.e.
> >>>> code that implements public APIs will continue to compile.
> >>>>
> >>>>
> >>>> But for minor release, it is a liitle inexplicit.
> >>>>
> >>>> A minor upgrade requires no application/client code modification.
> >>>> Ideally
> >>>> it would be a drop-in replacement but client code, coprocessors,
> >>>> filters,
> >>>> etc might have to be recompiled if new jars are used.
> >>>>
> >>>> If no client code modification is required, then we are not allowed to
> >>>>
> >>> add
> >>>
> >>>> methods to interface as it will cause compliation error if user
> extends
> >>>>
> >>> the
> >>>
> >>>> interface as on branch-1, we still need to support JDK7 which does not
> >>>> support default method. But I think this will make minor release
> almost
> >>>>
> >>> the
> >>>
> >>>> same with patch release? And another point is that, for most users,
> they
> >>>> only use the interface and do not implement it, so adding methods will
> >>>>
> >>> not
> >>>
> >>>> break their code.
> >>>>
> >>>> So here we want to see what the community think of whether we should
> >>>>
> >>> allow
> >>>
> >>>> adding methods to interface in minor release. Any comments are
> welcomed.
> >>>>
> >>>>
> >>>> I'd suggest we add to the refguide a clarification that allows
> addition
> >>> of
> >>> new methods to Interfaces in minor releases. Here is a suggested
> >>> addition:
> >>>
> >>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may
> have
> >>> to
> >>> recompile. We reserve the right to add new methods to existing
> Interfaces
> >>> on minor updates (this will be less of an issue in hbase-2.0.0 which
> >>> requires JDK8; JDK8 allows specification of 'default' implementations
> of
> >>> Interface methods)"
> >>>
> >>> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
> >>>
> >>> St.Ack
> >>>
> >>>
> >>>
> >>> Thanks.
> >>>>
> >>>>
> >>
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Stack <st...@duboce.net>.
On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <el...@apache.org> wrote:
> +1 to the JDK8 default implementation approach. I'd say this would be good
> to push forward for the future.
>
> For 1.x, I see no reason why we couldn't provide concrete implementations
> as a stop-gap. Identifying and creating those classes is probably the
> biggest barrier :). I don't think anything really stops us from doing this
> now...
>
>
I can change the wording to say we will make a best effort at providing a
default implementation but allow that it may not be always possible.
St.Ack
>
> James Taylor wrote:
>
>> How about the idea of HBase having base implementations for common
>> interfaces? That would often help applications built on top of HBase to
>> maintain backward compatibility from release to release.
>>
>> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
>>
>> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org> wrote:
>>>
>>> There are some comments in https://issues.apache.org/
>>>> jira/browse/HBASE-17584
>>>> .
>>>>
>>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the
>>>> method
>>>> to ResultScanner which is an interface and part of our public API.
>>>>
>>>> In our refguide, it is clear that we can do this for a major release.
>>>> And for patch release, it is also clear that we are not allowed to do
>>>>
>>> this.
>>>
>>>> New APIs introduced in a patch version will only be added in a source
>>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]: i.e.
>>>> code that implements public APIs will continue to compile.
>>>>
>>>>
>>>> But for minor release, it is a liitle inexplicit.
>>>>
>>>> A minor upgrade requires no application/client code modification.
>>>> Ideally
>>>> it would be a drop-in replacement but client code, coprocessors,
>>>> filters,
>>>> etc might have to be recompiled if new jars are used.
>>>>
>>>> If no client code modification is required, then we are not allowed to
>>>>
>>> add
>>>
>>>> methods to interface as it will cause compliation error if user extends
>>>>
>>> the
>>>
>>>> interface as on branch-1, we still need to support JDK7 which does not
>>>> support default method. But I think this will make minor release almost
>>>>
>>> the
>>>
>>>> same with patch release? And another point is that, for most users, they
>>>> only use the interface and do not implement it, so adding methods will
>>>>
>>> not
>>>
>>>> break their code.
>>>>
>>>> So here we want to see what the community think of whether we should
>>>>
>>> allow
>>>
>>>> adding methods to interface in minor release. Any comments are welcomed.
>>>>
>>>>
>>>> I'd suggest we add to the refguide a clarification that allows addition
>>> of
>>> new methods to Interfaces in minor releases. Here is a suggested
>>> addition:
>>>
>>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have
>>> to
>>> recompile. We reserve the right to add new methods to existing Interfaces
>>> on minor updates (this will be less of an issue in hbase-2.0.0 which
>>> requires JDK8; JDK8 allows specification of 'default' implementations of
>>> Interface methods)"
>>>
>>> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
>>>
>>> St.Ack
>>>
>>>
>>>
>>> Thanks.
>>>>
>>>>
>>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Josh Elser <el...@apache.org>.
+1 to the JDK8 default implementation approach. I'd say this would be
good to push forward for the future.
For 1.x, I see no reason why we couldn't provide concrete
implementations as a stop-gap. Identifying and creating those classes is
probably the biggest barrier :). I don't think anything really stops us
from doing this now...
James Taylor wrote:
> How about the idea of HBase having base implementations for common
> interfaces? That would often help applications built on top of HBase to
> maintain backward compatibility from release to release.
>
> On Wed, Mar 15, 2017 at 10:38 PM Stack<st...@duboce.net> wrote:
>
>> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zh...@apache.org> wrote:
>>
>>> There are some comments in https://issues.apache.org/
>>> jira/browse/HBASE-17584
>>> .
>>>
>>> In HBASE-17584, we want to remove Scan.getScanMetrics and move the method
>>> to ResultScanner which is an interface and part of our public API.
>>>
>>> In our refguide, it is clear that we can do this for a major release.
>>> And for patch release, it is also clear that we are not allowed to do
>> this.
>>> New APIs introduced in a patch version will only be added in a source
>>> compatible way [1<http://hbase.apache.org/book.html#_footnote_1>]: i.e.
>>> code that implements public APIs will continue to compile.
>>>
>>>
>>> But for minor release, it is a liitle inexplicit.
>>>
>>> A minor upgrade requires no application/client code modification. Ideally
>>> it would be a drop-in replacement but client code, coprocessors, filters,
>>> etc might have to be recompiled if new jars are used.
>>>
>>> If no client code modification is required, then we are not allowed to
>> add
>>> methods to interface as it will cause compliation error if user extends
>> the
>>> interface as on branch-1, we still need to support JDK7 which does not
>>> support default method. But I think this will make minor release almost
>> the
>>> same with patch release? And another point is that, for most users, they
>>> only use the interface and do not implement it, so adding methods will
>> not
>>> break their code.
>>>
>>> So here we want to see what the community think of whether we should
>> allow
>>> adding methods to interface in minor release. Any comments are welcomed.
>>>
>>>
>> I'd suggest we add to the refguide a clarification that allows addition of
>> new methods to Interfaces in minor releases. Here is a suggested addition:
>>
>> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have to
>> recompile. We reserve the right to add new methods to existing Interfaces
>> on minor updates (this will be less of an issue in hbase-2.0.0 which
>> requires JDK8; JDK8 allows specification of 'default' implementations of
>> Interface methods)"
>>
>> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
>>
>> St.Ack
>>
>>
>>
>>> Thanks.
>>>
>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by James Taylor <ja...@apache.org>.
How about the idea of HBase having base implementations for common
interfaces? That would often help applications built on top of HBase to
maintain backward compatibility from release to release.
On Wed, Mar 15, 2017 at 10:38 PM Stack <st...@duboce.net> wrote:
> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang <zh...@apache.org> wrote:
>
> > There are some comments in https://issues.apache.org/
> > jira/browse/HBASE-17584
> > .
> >
> > In HBASE-17584, we want to remove Scan.getScanMetrics and move the method
> > to ResultScanner which is an interface and part of our public API.
> >
> > In our refguide, it is clear that we can do this for a major release.
> > And for patch release, it is also clear that we are not allowed to do
> this.
> >
> > New APIs introduced in a patch version will only be added in a source
> > compatible way [1 <http://hbase.apache.org/book.html#_footnote_1>]: i.e.
> > code that implements public APIs will continue to compile.
> >
> >
> > But for minor release, it is a liitle inexplicit.
> >
> > A minor upgrade requires no application/client code modification. Ideally
> > it would be a drop-in replacement but client code, coprocessors, filters,
> > etc might have to be recompiled if new jars are used.
> >
> > If no client code modification is required, then we are not allowed to
> add
> > methods to interface as it will cause compliation error if user extends
> the
> > interface as on branch-1, we still need to support JDK7 which does not
> > support default method. But I think this will make minor release almost
> the
> > same with patch release? And another point is that, for most users, they
> > only use the interface and do not implement it, so adding methods will
> not
> > break their code.
> >
> > So here we want to see what the community think of whether we should
> allow
> > adding methods to interface in minor release. Any comments are welcomed.
> >
> >
> I'd suggest we add to the refguide a clarification that allows addition of
> new methods to Interfaces in minor releases. Here is a suggested addition:
>
> "For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have to
> recompile. We reserve the right to add new methods to existing Interfaces
> on minor updates (this will be less of an issue in hbase-2.0.0 which
> requires JDK8; JDK8 allows specification of 'default' implementations of
> Interface methods)"
>
> I could add a further qualifier only applies to hbase-1.4.0 and beyond?
>
> St.Ack
>
>
>
> > Thanks.
> >
>
Re: About adding methods to an interface which is part of our public
API in minor release
Posted by Stack <st...@duboce.net>.
On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang <zh...@apache.org> wrote:
> There are some comments in https://issues.apache.org/
> jira/browse/HBASE-17584
> .
>
> In HBASE-17584, we want to remove Scan.getScanMetrics and move the method
> to ResultScanner which is an interface and part of our public API.
>
> In our refguide, it is clear that we can do this for a major release.
> And for patch release, it is also clear that we are not allowed to do this.
>
> New APIs introduced in a patch version will only be added in a source
> compatible way [1 <http://hbase.apache.org/book.html#_footnote_1>]: i.e.
> code that implements public APIs will continue to compile.
>
>
> But for minor release, it is a liitle inexplicit.
>
> A minor upgrade requires no application/client code modification. Ideally
> it would be a drop-in replacement but client code, coprocessors, filters,
> etc might have to be recompiled if new jars are used.
>
> If no client code modification is required, then we are not allowed to add
> methods to interface as it will cause compliation error if user extends the
> interface as on branch-1, we still need to support JDK7 which does not
> support default method. But I think this will make minor release almost the
> same with patch release? And another point is that, for most users, they
> only use the interface and do not implement it, so adding methods will not
> break their code.
>
> So here we want to see what the community think of whether we should allow
> adding methods to interface in minor release. Any comments are welcomed.
>
>
I'd suggest we add to the refguide a clarification that allows addition of
new methods to Interfaces in minor releases. Here is a suggested addition:
"For a minor release, IF YOU HAVE IMPLEMENTED AN INTERFACE, you may have to
recompile. We reserve the right to add new methods to existing Interfaces
on minor updates (this will be less of an issue in hbase-2.0.0 which
requires JDK8; JDK8 allows specification of 'default' implementations of
Interface methods)"
I could add a further qualifier only applies to hbase-1.4.0 and beyond?
St.Ack
> Thanks.
>