Lots of static methods in an interface

Paul Benedict pbenedict at apache.org
Tue Sep 10 10:06:15 PDT 2013


Zhong, Brian has often quipped there is a JavaDoc overhaul planned for Java
9. You'll have to stay tuned for a few years to see a better representation
of things.


On Tue, Sep 10, 2013 at 11:29 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

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


-- 
Cheers,
Paul


More information about the lambda-dev mailing list