[
https://issues.apache.org/jira/browse/HDFS-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011486#comment-14011486
]
Steve Loughran commented on HDFS-6418:
--------------------------------------
-there's no other place in the hdfs codebase that defines the properties for
hdfs as constant strings...anyone who doesn't want to cut and paste values is
going to link to this.
Which is preferable?
# people cut and pasting strings like {"dfs.replication"}
# people importing constants defined in the hadoop source, as is done via
{{YarnConfiguration}} and {{CommonConfigurationKeysPublic}}?
I may have been unusual in that I tried to use the in-source constants. And I
may have (unintentionally) used them despite them being annotated private -but
when you do YARN code you end up treating that as a mild hint anyway.
Options
# do nothing, I fix my code to inline the constant in my own constants class. I
repeat this for any other imports in my code, as I can no longer be confident
that they will remain there. Anyone else who uses the constant finds their code
breaks.
# Add a deprecated definition of the old name, using the new name as its
reference.
# action #2, then extract a stable set of constants into a HDFSPublicKeys class
for others to use, make this a superclass of the private keys, and encourage
people to use these constants in future.
Now -how are static strings imported into other classes in the compiler? Copied
or linked? If copied, code that imports the old definitions will not fail at
runtime -only when precompiled. Which would reduce the damage somewhat
> Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
> -------------------------------------------------------
>
> Key: HDFS-6418
> URL: https://issues.apache.org/jira/browse/HDFS-6418
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs-client
> Affects Versions: 3.0.0, 2.5.0
> Reporter: Steve Loughran
>
> Code i have that compiles against HADOOP 2.4 doesn't build against trunk as
> someone took away {{DFSConfigKeys.DFS_NAMENODE_USER_NAME_KEY}} -apparently in
> HDFS-6181.
> I know the name was obsolete, but anyone who has compiled code using that
> reference -rather than cutting and pasting in the string- is going to find
> their code doesn't work.
> More subtly: that will lead to a link exception trying to run that code on a
> 2.5+ cluster.
> This is a regression: the old names need to go back in, even if they refer to
> the new names and are marked as deprecated
--
This message was sent by Atlassian JIRA
(v6.2#6252)
