Final defenders

[Zhong Yu]

Static methods in interfaces would be great - these methods naturally
belong in the same namespace; to invent another namespace just to host
them is an unfortunate limitation of the language.

But if we move all Collections methods to Collection interface,
javadoc better be changed so that static methods are grouped
separately, like constructors are.

Another question would be, for a namespace like java.lang.Math, that
does nothing but host some static methods, should it be a class or an
interface?

Zhong Yu

On Tue, Aug 7, 2012 at 1:16 PM, Daniel Latrémolière
<daniel.latremoliere at gmail.com> wrote:
>
>> Hi,
>>
>> these methods should be in a class if they are useful. E.g. in
>> java.util.Collections.
>>
>> Z.
> By being in List interface, they are easier to find. In an external
> class, they have a very small value comparing to current constructors.
> Static methods from classes like Collections, Arrays are not useful for
> beginners because they are impossible to find in a very big API like Java).
>
> But, if you know that all lifecycle (factory for creation, change of
> content, etc.) of a List is managed by List interface, you know exactly
> where to find the solution of your problem. You can even publish a
> subset of javadocs of Java without implementing classes like ArrayList,
> LinkedList, etc. which will be much more clear for learning Java and
> attracting new users.
>
> A defender method in interface can too be a method in Collections class
> (even allowing specialized implementation with a service to be
> implemented), but this is always more difficult to find and it give
> globally a very complex API.
>
> Daniel.
>