[jira] [Resolved] (MAPREDUCE-6368) Unreachable Java code

["Jorge Gabriel Siqueira (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MAPREDUCE-6368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jorge Gabriel Siqueira resolved MAPREDUCE-6368.
-----------------------------------------------
    Resolution: Invalid
      Assignee: Dhiraj Nilange

This issue is not valid. In the second iteration of the loop the value of last will be set to k: {code:java}last = k;{code}

So, as the condition is last >= k, the code will be used.

{code:java}
float stepSize = samples.length / (float) numPartitions;
int last = -1;
for(int i = 1; i < numPartitions; ++i) {
  int k = Math.round(stepSize * i);
  while (last >= k && comparator.compare(samples[last], samples[k]) == 0) {
    ++k;
  }
  writer.append(samples[k], nullValue);
  last = k;
}
{code}

> Unreachable Java code
> ---------------------
>
>                 Key: MAPREDUCE-6368
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6368
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv2
>    Affects Versions: 2.6.0
>            Reporter: Dhiraj Nilange
>            Assignee: Dhiraj Nilange
>            Priority: Minor
>
> Reference
> Class: org.apache.hadoop.mapreduce.lib.partition.InputSampler
> Method: writePartitionFile
> Line: 337
> The issue exists in the following code loop at line 337:-
> while (last >= k && comparator.compare(samples[last], samples[k]) == 0) 
> {
>       ++k; 
>  }
> The problem is that the first condition in the while loop (last >= k) will always be false. The value of 'last' will always be lesser than 'k' and hence the first condition will never evaluate to true. There is second condition as well but since it is appearing as AND condition, that will never be checked since the first condition itself is false. Hence this loop is not contributing towards the code output anyways. If this was intended to execute, then I guess it will need investigation. But from what I have noticed, it doesn't seem to harm the output of the method. In that case why even keep it there. We could very well remove it from the code. And if this was done with the some other intention, in that case this needs to be corrected as currently it is unreachable code. This issue very much exists in the release 2.6.0, I have not seen the release 2.7.0 source code, but it may very well exist in that as well (it's worth checking).
> Thanks & Regards,
> Dhiraj



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)