I just committed this. Thanks, Runping!

Yeah, I agree with Doug that Runping's fix is the right one for the short term and the context parameter is the right long term solution.

The way I see it, reporter is just another output stream coming out of the task. It should get a uniform treatment just like other streams. Context is a good abstraction, since we would be able to hang non-Strings (such as the task's stream-set) to it.

> the right way to do this is by supplying a reporter in all methods of tasks

I'm not sure exactly how that addresses this issue.

I think we ought to add a Context parameters to most methods on core interfaces, that we can then effectively add and remove/deprecate parameters from these interfaces without breaking implementations. For example, Owen made this a part of his proposal in HADOOP-904. So, as we next modify each interface, I think we ought to convert to this style. And Reporter could then be added as a getReporter() method to the context parameter used by most interfaces, removing it from the explicit parameter list, and solving this issue. But that's a long-term fix. The short term fix Runping attached is probably a good idea in the meantime, no?

+1, because http://issues.apache.org/jira/secure/attachment/12350967/hadoop-1010.patch applied and successfully tested against trunk revision r505557.

I think the right way to do this is by supplying a reporter in all methods of tasks (configure, map/reduce, close). (See HADOOP-403).

Added Reporter.NULL constant.

This patch adds a NULL constant to Reporter interface.

Alternately, we could provide a Reprter.NULL constant that could be passed in such cases.

public static final Reporter NULL = new Reporter() { public void setStatus(String s) {} };