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 <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. > >>>> > >>>> > >> > -- Best regards, - Andy If you are given a choice, you believe you have acted freely. - Raymond Teller (via Peter Watts)
