Lots of static methods in an interface

[Sam Pullara]

The tabs at the top seem pretty good for now. I'm not too concerned about it.

Sam

On Sep 10, 2013, at 10:06 AM, Paul Benedict <pbenedict at apache.org> wrote:

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