Protected in Interfaces

Solution 1:

Because an interface is supposed to mean "what you can see from outside the class". It would not make sense to add non-public methods.

Solution 2:

Although the often quoted reason is that "interfaces define public APIs", I think that is an over-simplification. (And it "smells" of circular logic too.)

It would not be meaningless to have interfaces that have a mixture of access modifiers; e.g. partly public and partly restricted to other classes in the same package as the interface. In fact, in some cases this could be down-right useful, IMO.

Actually, I think that the part of reasoning behind making members of an interface implicitly public is that it makes the Java language simpler:

• Implicitly public interface members are simpler for programmers to deal with. How many times have you seen code (classes) where the method access modifiers were chosen seemingly at random? A lot of "ordinary" programmers have difficulty understanding how best to manage Java abstraction boundaries¹. Adding public/protected/package-private to interfaces makes it even harder for them.

• Implicitly public interface members simplify the language specification ... and hence the task for Java compiler writers, and the folks who implement the Reflection APIs.

The line of thinking that the "interfaces define public APIs" is arguably a consequence (or characteristic) of the simplifying language design decision ... not the other way around. But in reality, the two lines of thought probably developed in parallel in the minds of the Java designers.

At any rate, the official response to the RFE in JDK-8179193 makes it clear that the Java design team decided² that allowing protected on interfaces adds complexity for little real benefit. Kudos to @skomisa for finding the evidence.

The evidence in the RFE settles the issue. That is the official reason why that has not been added.

^{1 - Of course, top-gun programmers have no difficulty with these things, and may welcome a richer palette of access control features. But, what happens when their code is handed over to someone else to maintain?}

^{2 - You may disagree with their decision or their stated reasoning but that is moot.}

Solution 3:

I have to say that this question has been re-opened by the introduction of default methods in Java 8. The project that I am working on right now is, similar to the base nature of an interface, meant to abstract intention from implementation.

There are several cases in which I could drastically simplify my code with a "default protected" method. It turns out that that doesn't actually work, as interfaces still stick to Java 7 logic. A normal protected method doesn't especially make any sense, for the reasons mentioned above; but if a default public method requires a low-level resource that will not likely change and can be provided by a protected method, it seems to me that having "default protected" work would not only maintain cleaner code, it would protect future users from accidental abuses.

(This tragically does not change the fact that I still need to over-complicate my code with otherwise unnecessary abstracts; but I do intend to put a feature request in at Oracle.)

Solution 4:

Because interfaces define public APIs. Anything that's protected is an internal detail which does not belong in an interface.

You can use abstract classes with protected abstract methods, but interfaces are restricted to public methods and public static final fields.