Lots of static methods in an interface
spullara at gmail.com
Tue Sep 10 10:19:04 PDT 2013
The tabs at the top seem pretty good for now. I'm not too concerned about it.
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
>>> 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