Thanks for the patches. This should get in soon cause its a wide divide between old and new API feature sets.
I have a few questions though:
MAPREDUCE-1501 added this behaviour to the old API. Can you change your patch to share code and tests so that both the old and new API behave in the same way? Also, the old configuration parameter should be deprecated, but still supported in the new API.
Given that both APIs are now supported, do we really need the deprecation? Will the new name apply to both? Are other properties handled in the same way today?
For example I see in old API the following reuse:
public static final String NUM_INPUT_FILES =
While this patch does not change similar things in mapred.lib even after deprecation marker. Can this be done here too?
Can the test not be done with just LFS? We can avoid a dependency if it can be done. Similarly a LJRunner test would be great too, if alright - instead of an MR cluster.
The last part can still be bettered I think. (Nit: Its not reading recursively, just listing that way.) Perhaps "mapreduce.input.fileinputformat.input.dir.recursive" is simpler to have?