Lots of static methods in an interface

[Brian Goetz]

> 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 
esoteric.

> However I still find the javadoc landing page very messy:
>
> http://download.java.net/jdk8/docs/api/java/util/Comparator.html#method_summary
>
> 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 
perfect.