It is true that for classes the methods can sometimes be located on the class itself -- I have heard some vitriolic rants against the use of a "Foos" class of static utilities when Foo is not an interface.
However, sometimes the methods you want conflict with the instance methods of the class. For example, in Google Collections, we can't offer "Ordering.reverse()" as a shortcut for "Ordering.natural().reverse()". Also, static methods on a non-final class can be problematic. You have to be very careful to remember to "fauxveride" them in all subclasses -- unless they just happen to do what the user would expect even when qualified with the name of the subclass. "create()" methods are especially vulnerable to this. You also get other nonintuitive clashes between the parent class's static methods and the child class's static methods, including some that JDK 6 allows but JDK 7 won't. We deeply regret our ImmutableSet.copyOf() and so forth; we'd have been much better off to keep those methods in a separate class. Anyway, point is, the Foos convention is not so bad. On Wed, Nov 11, 2009 at 10:51 AM, Neal Gafter <n...@gafter.com> wrote: > That convention has been around a while for interfaces. Why the convention > is being used for the class FileSystem I don't know. > > > On Wed, Nov 11, 2009 at 10:13 AM, Ulf Zibis <ulf.zi...@gmx.de> wrote: > >> Hi all, >> >> is that new JDK convention having *s classes for static methods? >> Refer to java.nio.file.FileSystem vs. java.nio.file.FileSystems. >> >> -Ulf >> >> >> > -- Kevin Bourrillion @ Google internal: http://go/javalibraries external: guava-libraries.googlecode.com
