hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: About adding methods to an interface which is part of our public API in minor release
Date Thu, 16 Mar 2017 18:35:46 GMT
+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 <elserj@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<stack@duboce.net>  wrote:
>>
>> On Wed, Mar 15, 2017 at 10:28 PM, Duo Zhang<zhangduo@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.
>>>>
>>>>
>>

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