Simply instantiating a Glob object when the path might not be a glob may be problematic. Perhaps a better way to handle might be to have a static Path.create(String) which returns either a Path or GlobPath.
Distinguishing intent where the Path is created (as above) could solve part of the problem with
HADOOP-8709 (caller can resolve which API to use?), but I don't think a subtype of Path will solve the other issues. Dispatch is still on the static type, so nothing is solved for the callee.
The first was to simply have a base path and a string pattern as the parameters to globStatus. I thought it would be better to encapsulate the two into a single Glob object so it is obvious when an API takes a glob and when it does not.
Having an API advertise its "globiness" is useful, I like it. Though users specifying a single resource will need to create Glob objects on top of Path objects which are really URIs... which seems unnecessarily confusing. Still, methods for Configuration are also straightforward; setGlob() would need to escape everything in the URI side first (so users could continue to specify globs on the commandline as Paths with special characters), but aside from that it seems straightforward. "Correcting" it everywhere in the code may be prohibitive, though...
Since many of these are user-facing, do you think we need a more specific type than String for the glob part? ls /users/hadoop/*.foo translated into:
fs.globStatus(new Glob(new Path("hdfs:), Pattern.compile("*.foo")))
seems like it's strayed from sanity...