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 questions. Opinions? best, Colin On Tue, Jun 11, 2013 at 4:09 PM, Andrew Wang <andrew.w...@cloudera.com> 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. > > HTH, > Andrew > > > On Tue, Jun 11, 2013 at 3:18 PM, Ravi Prakash <ravi...@ymail.com> 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 >> method >> >> @deprecated API only for 0.20-append >> FileSystem.createNonRecursive. >> >> >> 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? >> Thanks >> Ravi
