[
https://issues.apache.org/jira/browse/HBASE-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335037#comment-15335037
]
Andrew Purtell commented on HBASE-16048:
----------------------------------------
It's a fair question [~jrottinghuis].
Because coprocessors are internal extension points there are going to be
internal types in method signatures. When they are used as opaque references
all is well. When we are approached by users wanting compatibility guarantees -
because they are going to inherit as a base class or implement the interface -
in the past we sometimes have replaced the internal type with a supportable
interface, see HBASE-12972 and HBASE-12975 as two examples.
In this case, InternalScanner not only is found in method signatures but
coprocessor users, in order to extend scanning, must implement it. It is
already a stable interface. Would it not be what we would come up with if
performing another exercise here like HBASE-12972?
> Consider tagging InternalScanner with
> LimitedPrivate(HBaseInterfaceAudience.COPROC)
> ------------------------------------------------------------------------------------
>
> Key: HBASE-16048
> URL: https://issues.apache.org/jira/browse/HBASE-16048
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
>
> Some methods (preCompact, preCompactScannerOpen, preFlush,
> preFlushScannerOpen, etc) of BaseRegionObserver take InternalScanner as input
> argument as well as the return type.
> BaseRegionObserver is tagged with
> @InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC) but
> InternalScanner is tagged with @InterfaceAudience.Private.
> This JIRA is to discuss tagging InternalScanner with
> @InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
