On Thu, Mar 16, 2017 at 11:02 AM, Josh Elser <els...@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<zhang...@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. >>>> >>>> >>
