New convention for static methods ?

Kevin Bourrillion kevinb at
Thu Nov 12 20:35:29 UTC 2009

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

Anyway, point is, the Foos convention is not so bad.

On Wed, Nov 11, 2009 at 10:51 AM, Neal Gafter <neal at> 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.Zibis at> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list