[ https://issues.apache.org/jira/browse/HBASE-11679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089386#comment-14089386 ]
stack commented on HBASE-11679: ------------------------------- Fails to apply since yesterday's big commit (files removed and two little rejects). I tried to bring it over but TestEndToEndSplitTransaction proves a little awkward. See what you think [~carterpage] Went through the patch looking for API breakage to see if "...did not change any public or protected method return values, since that would violate criteria #1 above and break compatibility" holds. LGTM. Bulk of changes are in test otherwise, internal changes; no API change. +1 on commit to master. +1 on commit to branch-1 but such a big change probably needs [~enis] blessing. > Replace "HTable" with "HTableInterface" where backwards-compatible > ------------------------------------------------------------------ > > Key: HBASE-11679 > URL: https://issues.apache.org/jira/browse/HBASE-11679 > Project: HBase > Issue Type: Improvement > Reporter: Carter > Assignee: Carter > Attachments: HBASE_11679.patch, HBASE_11679.patch > > > This is a refactor to move more of the code towards using interfaces for > proper encapsulation of logic. > The amount of code touched is large, but it should be fairly easy to review. > It changes variable declarations from HTable to HTableInterface where the > following holds: > # The declaration being updated won't break assignment > # The declaration change does not break the compile (eg trying to access > non-interface methods) > The two main situations are to change something like this: > {code} > HTable h = new HTable(c, tn); > {code} > to > {code} > HTableInterface h = new HTable(c, tn); > {code} > and this: > {code} > public void doSomething(HTable h) { ... } > {code} > to this: > {code} > public void doSomething(HTableInterface h) { ... } > {code} > This gets most of the obvious cases out of the way and prepares for more > complicated interface refactors in the future. In method signatures, I > changed parameters, but did _not_ change any public or protected method > return values, since that would violate criteria #1 above and break > compatibility. -- This message was sent by Atlassian JIRA (v6.2#6252)