[
https://issues.apache.org/jira/browse/HBASE-26817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503674#comment-17503674
]
Sean Busbey commented on HBASE-26817:
-------------------------------------
I understand the rationale for not allowing parent classes with less permissive
audiences than children and can get behind it.
I don't think it'll serve our interests to apply the other direction as a
blanket approach. For example, we use public abstract classes as a way to
provide help to downstream implementers of public interfaces where we want the
option of someone providing an alternate implementation but we want our default
implementation to be private. I usually want to keep the scope of LP(PHOENIX)
promises as small as possible.
In the specific case of these other implementations for RpcExecutor I don't
have a strong opinion. If I was going to personally dig in, I'd be interested
in finding out _why_ they were marked differently. If it's just a matter of
them trying to match RpcExecutor because they didn't exist when Phoenix asked
for the other subclasses to be LimitedPrivate, then it seems reasonable to make
them LimitedPrivate.
> Mark RpcExecutor as IA.LimitedPrivate COPROC and PHOENIX
> --------------------------------------------------------
>
> Key: HBASE-26817
> URL: https://issues.apache.org/jira/browse/HBASE-26817
> Project: HBase
> Issue Type: Task
> Components: compatibility
> Affects Versions: 2.5.0, 3.0.0-alpha-2, 2.6.0, 2.4.10
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Priority: Major
>
> {{RpcExecutor}}, an abstract base class, is marked as {{IA.Private}}.
> However, it has several subclasses that are marked as
> {{IA.LimitedPrivate(COPROC, PHOENIX)}}. I think that the base class needs to
> match the highest exposure level of any of its subclasses.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
