Rename Files to not conflict with java.nio.file.Files

[GoogleCodeExporter]

Java 7's NIO.2 has a Files utility class. I was hoping that, similar to 
Collections2, you guys would rename the class so it won't conflict for those of 
us that use both.

Original issue reported on code.google.com by dhar...@jive.com on 10 Jan 2014 at 6:10

[GoogleCodeExporter]

Objects is the same case. Using full name is not so much inconvenient, though, 
this issue should IMHO handle both cases consistently.

Original comment by tomas.za...@gmail.com on 10 Jan 2014 at 7:35

[GoogleCodeExporter]

Our new naming convention for resolving duplicate class names is "MoreFoos".  
So eventually we will have base.MoreObjects to go with java.util.Objects.

Colin should be able to answer whether or not we plan to do the same for Files.

Original comment by kak@google.com on 10 Jan 2014 at 8:22

• Added labels: Type-Enhancement
• Removed labels: Type-Addition

[GoogleCodeExporter]

+1 for MoreFoos. It's way nicer than Foos2!

Original comment by SeanPFl...@googlemail.com on 10 Jan 2014 at 9:07

[GoogleCodeExporter]

I agree, but it would be nice to have it consistent. With some classes being 
Foos2 and others being MoreFoos, it’s a little confusing on what to look for.

David Harris
Software Developer  |  Jive Communications, Inc.
Jive.com  |  801.426.5782 ext. 1000 |  dharris@getjive.com

On January 10, 2014 at 2:08:07 AM, guava-libraries@googlecode.com 
(guava-libraries@googlecode.com) wrote:

Original comment by dhar...@jive.com on 10 Jan 2014 at 9:09

[GoogleCodeExporter]

We don't currently have any plans to rename Files to MoreFiles (or Files2). 
Particularly given that our internal Files-like class for working with NIO.2 
Paths is called MoreFiles. I hadn't placed much importance on renaming our 
Files class since it seemed like it would be relatively uncommon to be using 
both the old java.io.File API and the new file APIs in the same class, and if 
you aren't using java.io.File there isn't much reason to use our Files class at 
all.

Original comment by cgdecker@google.com on 10 Jan 2014 at 4:45

• Changed title: Rename Files to not conflict with java.nio.file.Files
• Changed state: Research

[GoogleCodeExporter]

Re. consistency:

Collections2 is sadly a bit of a wart we're "stuck with". We made the decision 
to use the "More" prefix a while ago, hence MoreExecutors.

Original comment by kak@google.com on 10 Jan 2014 at 5:13

[GoogleCodeExporter]

My use case is fairly simple: I’m watching a directory for changes to files 
of a specific extension. I’m using NIO2 Files for it ‘newDirectoryStream’ 
method, and Guava’s Files for the ‘getFileExtension’ method.

David Harris
Software Developer  |  Jive Communications, Inc.
Jive.com  |  801.426.5782 ext. 1000 |  dharris@getjive.com

On January 10, 2014 at 10:13:21 AM, guava-libraries@googlecode.com 
(guava-libraries@googlecode.com) wrote:

Original comment by dhar...@jive.com on 10 Jan 2014 at 5:49

[GoogleCodeExporter]

One way you could avoid having to fully qualify com.google.common.io.Files in 
the body of your code would be to do a static import of getFileExtension.

Original comment by cgdecker@google.com on 10 Jan 2014 at 6:40

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:10

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:07

• Added labels: Restrict-AddIssueComment-Commit