Explicit public on static interface methods?

[Remi Forax]

On 05/15/2013 06:27 AM, Andrey Breslav wrote:
>> John Rose made this observation/suggestion:
>>
>> Implicit public considered risky:  After working for a while on a new interface, I realized that all the methods I coded without an explicit "public" keyword were still public.  I was using them as package privates shared between the interface and some package-private implementation logic.  Oops.  Did not discover this until I was preparing a javadoc for public review.  That feels a little too late. Our processes would block me from accidentally introducing a public static, but that might not be true of customers.
>>
>> Suggest requiring a "public" on "static" interface members.  Will reduce confusion if we allow non-public statics in the future.
>>
> Observation 1: We will never be able to have package-private members in interfaces, unless we require explicit public now.

or we accept 'package' as a valid keyword for access modifiers.

> Observation 2: Having static methods and fields inconsistently handled for interfaces looks ugly. Fields are public by default, so making methods package-private by default would look odd. (By observation 1, we can't have package-private fields in interfaces).

yes.

In my opinion, the best is to stay with public as the default modifiers 
in interface
and modify the code convention to say that members of an interface 
should be declared public with the public modifier
so IDEs can emit a warning saying that a method with no modifier doesn't 
respect the code convention.

Rémi