Lots of static methods in an interface
brian.goetz at oracle.com
Tue Sep 10 09:29:59 PDT 2013
> It seems that the standard lib is settling on the convention of
I think "settling" is too strong a statement; more like "experimenting
to find the right equilibrium in the new world" is more accurate.
> putting static methods directly in the relevant interface, e.g.
> Comparator, instead of in another companion class, e.g. Comparators. I
> was against it before but now I think it is great - no need to direct
> users to another place to look for related methods.
Right. More generally, there are things to love about this approach (no
garbage side-classes, fewer "magic" place(s) to look for relevant static
methods), and things to worry about (messing up the interface with lots
of methods of varying relevance.) I think we should embrace both the
love and the worry.
In reality, I think the two poles -- the "old way" (put everything in a
side class) and "put everything in the interface" are both probably
excessive extremes. The poster child for this tension is Collections;
do we really want *all* of these methods in Collection? Some are pretty
> However I still find the javadoc landing page very messy:
> with static/abstract/default methods mixed together indiscriminately.
> Sure there are tabs, but there is no reason to give a bad first
> impression to users. Static/abstract/default methods are so different,
> does anybody really want an alphabetic index containing all of them?
Agreed. This was a compromise we made for Java 8. There are sooo many
things that need to be improved about Javadoc, that we were wary of
getting mired; this is what we had the resources to do for now. Its not
More information about the lambda-dev