Protected in Interfaces

Question

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.

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.}

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.)

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.

Several answers here employ circular reasoning to explain why interface methods can't be protected: it's because they have to be public, so obviously they can't be protected!

That explains nothing, but fortunately someone raised an enhancement request for protected methods in interfaces as a JDK bug a couple of years ago, which sheds some light on the issue:

Protected methods in interfaces: share across packages

Since modifiers are a bit limited in Java, a way to share methods across packages is restricted to public methods. Sometimes it is dangerous to make a method public, but it needs to be because of the lack of proper modifiers. My solution overcomes this limitation.

The java language specification doesn't currently allow the protected modifier for interface methods. We can take advantage of this fact and use protected for interface methods for this new feature.

If an interface method is marked protected and the interface is implemented by a class in another package, the method would not need to be public, but could also be private or at least package protected. The method is visible, what ever the class declares it to be and additionally visible in the source package of the interface (and sub packages?).

This way we could share certain methods across well known packages.

And this is the response to that enhancement request, which was closed with status Won't fix:

This proposal attempts to solve a problem in a way that adds complexity and special cases for little actual gain. A typical way to solve this problem is to have a private class that implements a public interface. The implementation methods are public, but are within a private class, so they remain private.

An alternative available starting in Java 9 is to make classes and methods public, but within a module that has a qualified-export to specific "friend" modules instead of being exported to the general public.

So the authoritative takeaways from that bug report are:

• The current situation is not going to change; interfaces are unlikely to ever support protected methods.
• The justification for not supporting protected methods in interfaces is that it "adds complexity and special cases for little actual gain".
• Since Java 9 there is an alternative approach for providing package level access to methods. Use the Java Platform Module System (JPMS) to "make classes and methods public, but within a module that has a qualified-export to specific "friend" modules instead of being exported to the general public".