HTableInterface is marked with: @InterfaceAudience.Public
@InterfaceStability.Stable It would be tricky if we move some methods out. Cheers On Mon, Feb 24, 2014 at 3:32 PM, lars hofhansl <[email protected]> wrote: > +1. Let's clean it up before 1.0. Including a clean HTableInterface. > The tricky part of HTableInterface was what to include in it. Up to this > point the guiding principle was to expose nothing of the internal > implementation (i.e. nothing about regions or start/end keys, etc). > > > Thanks for stepping in and finish the job that I should have finished, > Nick! > > > -- Lars > > > > ________________________________ > From: Nick Dimiduk <[email protected]> > To: hbase-dev <[email protected]> > Sent: Monday, February 24, 2014 3:03 PM > Subject: Cleanup HTable public interface > > > HBASE-6580 replaced the preferred means of HTableInterface acquisition to > the HConnection#getTable factory methods. HBASE-9117 removes the > HConnection cache, placing the burden of responsible connection cleanup on > whomever acquires it. > > The remaining HTable constructors use a Connection instance and manage > their own HConnection on the callers behalf. This is convenient but also a > surprising source of poor performance for anyone accustomed to the previous > connection caching behavior. I propose deprecating those remaining > constructors for 0.98/0.96 and removing them for 1.0. > > While I'm at it, I suggest we pursue some API hygiene in general and > convert HTable into an interface. Can that be done for 1.0 as well? >
