Explicit public on static interface methods?

[David Holmes]

On 15/05/2013 10:11 AM, David Holmes wrote:
> On 15/05/2013 9:50 AM, Brian Goetz 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.
>
> Obviously some education needed that the Java language only supports
> public interface members at this time. ;-)

Sorry that can be read the wrong way - no slight to John intended.

Java presently only allows public interface members and interface 
methods are abstract.

Java 8 adds the ability to define non-abstract methods. There is no 
change to the allowed accessibility so no reason to assume that you can 
write package-private "implementation" details in an interface. An 
interface is not a class and any Java programmer, existing or new, 
should be aware of the distinction. Of course now the distinction is far 
less clear than it was.

>> Suggest requiring a "public" on "static" interface members.  Will reduce
>> confusion if we allow non-public statics in the future.
>
> Didn't we already paint this bikeshed? Right now we only allow public
> members and the convention is that the public is implicit. If we were to
> change that then we should change it across the board - there is nothing
> special about static methods.

I think it far more likely to evoke confusion if we have arbitrarily 
different rules based on concrete vs abstract method. But may this is a 
transition path to requiring access modifiers in Java 9.

David

> David
>
>
>