This seems inconsistent. If the method is deprecated just because it's
in org.apache.hadoop.FileSystem, shouldn't all FileSystem methods be
marked as deprecated?
On the other hand, a user opening up FileSystem.java would probably
not realize that it is deprecated. The JavaDoc for the class itself
doesn't mention it, although the JavaDoc for a few of the methods
talks about a "transition".
It might make more sense to mark the class as a whole @deprecated if
that is the intent.
I did a quick search on JIRA, but didn't see anything answering these
On Tue, Jun 11, 2013 at 4:09 PM, Andrew Wang <[EMAIL PROTECTED]> wrote:
> Hi Ravi,
> I wasn't around for HADOOP-6840, but I'm guessing it's deprecated for the
> same reasons as primitiveCreate: FileSystem is supposed to eventually to be
> supplanted by FileContext.
> FileContext#create also has a more manageable number of method signatures
> through the use of flags, and in fact defaults to not creating parent
> directories. I believe MR2 also uses FileContext over FileSystem, so this
> might be your best bet.
> On Tue, Jun 11, 2013 at 3:18 PM, Ravi Prakash <[EMAIL PROTECTED]> wrote:
>> Hi folks,
>> I am trying to fix MAPREDUCE-5317. I noticed that the only way through
>> FileSystem to NOT recursively create directories is through the deprecated
>> @deprecated API only for 0.20-append
>> This has been marked deprecated ever since it was put in by HADOOP-6840.
>> Do we know if we ever expect to un-deprecate this method? I am trying to
>> find the rationale behind checking it in as a deprecated method, but
>> haven't been able to find any written record. Does anyone know?