[
https://issues.apache.org/jira/browse/HADOOP-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970127#comment-13970127
]
Haohui Mai commented on HADOOP-10506:
-------------------------------------
bq. The problem is if we ignore backwards compatibility when changing classes
marked LimitedPrivate used by downstream components then we are creating a
knife-switch type of upgrade, where upgrading the Hadoop core requires a
simultaneous corresponding update of
hive/pig/hbase/pick-your-favorite-LimitedPrivate-user.
Note that {{LimitedPrivate}} is a workaround of the lack of a strong concept of
symbol visibility in Java. It is a contract that is enforced voluntarily, but
not by the compiler. What it means is that classes with this annotation are not
supposed to be visible to the dependent projects. This is a contract between
hadoop-core and dependent projects.
Please consider the following scenarios:
# My code uses Java reflection to get an instance of {{BlockReaderLocal}},
which is a class only visible in the same package. The Java compiler will check
for that.
# My code uses {{RemoteBlockReader2}}, which is annotated with
{{InterfaceAudience.Private}}. The compiler won't check whether the code
violates the contract of visibility.
Note that in both cases they break the exact same contract of visibility. The
only difference is that whether the Java compiler can check for it. If you
agree that I probably should fix for (1), because "I'm doing it with my own
risks", how come I can dodge the responsibility of fixing for (2), which is
almost identical to the scenario described in this jira?
I understand that hadoop-core might not have the cleanest separation of public
/ private APIs, and it is important to be compatible. Having the options of
being incompatible, however, is critical to move forward in projects like
hadoop-core. I think a more reasonable approach is to drive some of the APIs to
be public and to clarify the contracts of compatibility between hadoop-core and
dependent projects, but not removing the contract and losing the option of
being incompatible in minor releases.
> LimitedPrivate annotation not useful
> ------------------------------------
>
> Key: HADOOP-10506
> URL: https://issues.apache.org/jira/browse/HADOOP-10506
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.0.0, 2.4.0
> Reporter: Thomas Graves
>
> The LimitedPrivate annotation isn't useful. The intention seems to have been
> those interfaces were only intended to be used by these components. But in
> many cases those components are separate from core hadoop. This means any
> changes to them will break backwards compatibility with those, which breaks
> the new compatibility rules in Hadoop.
> Note that many of the annotation are also not marked properly, or have fallen
> out of date. I see Public Interfaces that use LimitedPrivate classes in the
> api. (TokenCache using Credentials is an example).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
