[ 
https://issues.apache.org/jira/browse/HADOOP-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111702#comment-17111702
 ] 

Akira Ajisaka edited comment on HADOOP-17047 at 5/20/20, 2:49 AM:
------------------------------------------------------------------

Thanks [~rungroj] for reporting this and providing a patch, and thanks 
[~liuml07] for pinging me.

For the first case, now 'compile time dependency' is not correct. It is 
'runtime dependency' and this method is still required if we ensure binary 
compatibility with MRv1. If we are going to drop binary compatibility with 
MRv1, the method itself can be removed.

[http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html#Binary_Compatibility]
{quote}First, we ensure binary compatibility to the applications that use old 
mapred APIs. This means that applications which were built against MRv1 mapred 
APIs can run directly on YARN without recompilation, merely by pointing them to 
an Apache Hadoop 2.x cluster via configuration.
{quote}

Now we are on Hadoop 3, so we need to update the document in a separate jira.

For the second one, I think {{@VisibleForTesting}} can be used instead of {{/* 
This method is needed for tests. */}}.


was (Author: ajisakaa):
For the first case, now 'compile time dependency' is not correct. It is 
'runtime dependency' and this method is still required if we ensure binary 
compatibility with MRv1. If we are going to drop binary compatibility with 
MRv1, the method itself can be removed.

[http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html#Binary_Compatibility]
{quote}First, we ensure binary compatibility to the applications that use old 
mapred APIs. This means that applications which were built against MRv1 mapred 
APIs can run directly on YARN without recompilation, merely by pointing them to 
an Apache Hadoop 2.x cluster via configuration.
{quote}

Now we are on Hadoop 3, so we need to update the document in a separate jira.

For the second one, I think {{@VisibleForTesting}} can be used instead of {{/* 
This method is needed for tests. */}}.

> TODO comments exist in trunk while the related issues are already fixed.
> ------------------------------------------------------------------------
>
>                 Key: HADOOP-17047
>                 URL: https://issues.apache.org/jira/browse/HADOOP-17047
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Rungroj Maipradit
>            Assignee: Rungroj Maipradit
>            Priority: Trivial
>         Attachments: HADOOP-17047.001.patch
>
>
> In a research project, we analyzed the source code of Hadoop looking for 
> comments with on-hold SATDs (self-admitted technical debt) that could be 
> fixed already. An on-hold SATD is a TODO/FIXME comment blocked by an issue. 
> If this blocking issue is already resolved, the related todo can be 
> implemented (or sometimes it is already implemented, but the comment is left 
> in the code causing confusions). As we found a few instances of these in 
> Hadoop, we decided to collect them in a ticket, so they are documented and 
> can be addressed sooner or later.
> A list of code comments that mention already closed issues.
>  * A code comment suggests making the setJobConf method deprecated along with 
> a mapred package HADOOP-1230. HADOOP-1230 has been closed a long time ago, 
> but the method is still not annotated as deprecated.
> {code:java}
>  /**
>    * This code is to support backward compatibility and break the compile  
>    * time dependency of core on mapred.
>    * This should be made deprecated along with the mapred package 
> HADOOP-1230. 
>    * Should be removed when mapred package is removed.
>    */ {code}
> Comment location: 
> [https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/ReflectionUtils.java#L88]
>  * A comment mentions that the return type of the getDefaultFileSystem method 
> should be changed to AFS when HADOOP-6223 is completed.
>  Indeed, this change was done in the related commit of HADOOP-6223: 
> ([https://github.com/apache/hadoop/commit/3f371a0a644181b204111ee4e12c995fc7b5e5f5#diff-cd86a2b9ce3efd2232c2ace0e9084508L395)]
>  Thus, the comment could be removed.
> {code:java}
> @InterfaceStability.Unstable /* return type will change to AFS once
> HADOOP-6223 is completed */
> {code}
> Comment location: 
> [https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileContext.java#L512]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to