Why can't an interface be protected in java?

[Raghavendra Desoju]

Do we know why Java doesn't allow a protected interface?

[Roel De Nijs]

For the same reason it doesn't allow a protected class

[Raghavendra Desoju]

I do not know the reason for that either. Could you please clarify?

[Roel De Nijs]

protected and private can only be used by nested classes and/or interfaces. For example:

class Outer {
  protected class Inner1 {}
  private interface Inner2 {}
}

But for top-level classes and interfaces, it's not allowed.

Now the big question: why? First Let us have a look at all possible access levels:

private: only visible to this class

(default/package private): only visible to this class and classes in its package

protected: visible to this class, classes in the same package, and subclasses of this class

public: visible to any class

Let's first cover a private top-level class, because that's a pretty easy one: a private top-level class would be only visible to the class itself, so nothing would ever be able to access it => such a class is completely useless, so private is not allowed.

Now a protected top-level class, that's a little bit more tricky. Such a class would be accessible by classes in the same package and any of its subclasses. Now the (important) question remains: which classes are allowed to inherit from this protected class?

If it's all classes, then you could use the public access modifier instead.

If it's none of them, then the class could use the package-private (default) access level.

Maybe "some of them"? But there is no way to define which classes are allowed (besides the access modifier), so "some of them" is not possible

That's why protected is also not allowed.

Hope it helps!
Kind regards,
Roel

PS1. The same applies to interfaces as well of course.
PS2. Nested types (classes and/or interfaces) are not on the OCA exam, I just added them for completeness and demonstration purpose.

[Raghavendra Desoju]

Thanks for the explanation. This helps.

[Sachin Tripathi]

Thanks for (such a nice)question
After Roel's explanation,I have this in my mind regarding the topic
:
classes can be extended,
So if it is public ,it can be extended by all classes(even from outside package)
If it is package-private, it can be extended by classes (within package)
What will happen if it is protected
We get confused,we don't have any specific rule to define classes domain which can extend class

[Campbell Ritchie]

You do have a rule. It is exactly the same as protected for anything else.
Remember only a nested class can be protected (but not a local class)

[Sachin Tripathi]

I was talking about top level class :
If protected would have been allowed for top level class
Then we can't specify which class in the domain can subclass the protected class
If we allow it only for package,it will work like package-private
If we allow it for outside package, it will work like public

Now have I made myself clear?

[Roel De Nijs]

Sachin Tripathi wrote:Now have I made myself clear?

So you were just (exactly) repeating what I've said a few posts earlier?

[Sachin Tripathi]

Yes as you can see in my previous post in which I thanked op for good question, I clearly mentioned thanks to Roel(that is you)
And I tried writing your answer in my words,so as to test my understanding

[Roel De Nijs]

Sachin Tripathi wrote:And I tried writing your answer in my words,so as to test my understanding

Your understanding is correct!

And as for the exam: you won't get a question asking you why a top-level class can't be protected or private. But in a code snippet with some really complex loop you could have this class declaration

protected class Looping {
  // main-method with complex loop
}

So you know what to do if you spot a class declaration like this one, don't you?

[Sachin Tripathi]

Yup.
Will don't fall in the trap,
Just search for compilation error option in answer

[Mushfiq Mammadov]

Roel De Nijs wrote:

If it's all classes, then you could use the public access modifier instead.

If it's none of them, then the class could use the package-private (default) access level.

"none of them" or "the same package"?

[Henry Wong]

Mushfiq Mammadov wrote:

Roel De Nijs wrote:

If it's all classes, then you could use the public access modifier instead.

If it's none of them, then the class could use the package-private (default) access level.

"none of them" or "the same package"?

Well, it is kinda hard to elaborate based on the context, isn't it? Roel is *speculating* on possible purposes / behaviors for something that is *not* allowed, only to draw the conclusion that it is *not* allowed. Does it really matter that it is confusing? Heck, arguably, you can say that the confusion is one possible reason why it is not allowed...

Henry

[Winston Gutkowski]

Mushfiq Mammadov wrote:"none of them" or "the same package"?

It doesn't really matter.

There's one thing that hasn't been covered in this discussion (which started a while ago ), and that is that Java's interpretation of protected includes package access, which is NOT the case for all OO languages.

And on that basis, there is (IMO) no particularly good reason why top-level protected classes (or interfaces) aren't allowed, except for the fact that it's redundant.

If you want to make a class or interface available to other classes in a package, make it package-private. If you want to make it accessible only to subclasses of some class, make it nested and protected.

HIH

Winston

[Daniel Cox]

My conclusions from this thread are as follows:

There is no valid reason why a class or interface cannot be private so that it can be accessed only by:
- any class within the class

There is no valid reason why a class or interface cannot be protected so that it can be accessed only by:
- any class within the class
- any class within the class’s package
- any subclass outside the class’s package

A private class would be a standalone class that must not be accessed by any other class (except classes that are nested inside the private class). For example, the ImageFetcher class is a standalone class that simply fetches an image whose path is specified as a command-line argument:

private class ImageFetcher {
    private static Bitmap getImage(String args) {
		// image fetching code
	}
 
	private static void displayImage(Bitmap bitmap) {
		// image display code
	}

     public static void main(String args []) {
     	Bitmap bitmap = getImage(args);
     	displayImage(bitmap);
     }
 }

[Campbell Ritchie]

Daniel Cox wrote:. . . A private class would be a standalone class that must not be accessed by any other class, . . .

What is a standalone class? I think you have used the wrong word there. A private class is a member of another class and only exists inside that class, so you can only use it inside that other class. An example would be a linked list which has a private inner Node class. Node objects only ever exist inside the linked list and in this case they constitute part of the linked list. As Tim Cooke pointed out here, it is awkward to use an inner class (not static) outside its enclosing class, and Joshua Bloch in Effective Java™ recommends making inner classes private, but static nested classes can be public.

[Campbell Ritchie]

A few minutes ago, I wrote:. . . A private class . . . you can only use it inside that other class. . . .

Actually, that is not quite true. You can have a private inner class which implements a public interface or extends a public class and return an instance of that inner class as an instance of the other type. The Collections#unmodifiableList() method returns an instance of a private class which implements the List interface.

[Daniel Cox]

Campbell Ritchie wrote:A private class is a member of another class...

Sorry, my original comment was about top-level classes; not nested classes. Let me rephrase my original comment.

My conclusions are that there is no valid reason why a top-level class or interface cannot be private or protected.

Campbell Ritchie wrote:What is a standalone class? I think you have used the wrong word there.

Maybe it's the wrong term to use but I'm using the term "standalone" to describe a private top-level class that cannot be accessed by any other top-level class. It can be accessed only by classes that are nested within it.

[Henry Wong]

Daniel Cox wrote:Let me rephrase my original comment.

My conclusions are that there is no valid reason why a top-level class or interface cannot be private or protected.

Well, since it is hard speculating on something that doesn't exist, please take with a grain of salt...

I guess one issue would be how to bootstrap a private class. Since there is a requirement that the class be public, for the JVM to call its main() method, this makes running code in a private top-level class kinda not possible at the moment.

Henry

[Daniel Cox]

Henry Wong wrote:I guess one issue would be how to bootstrap a private class. Since there is a requirement that the class be public, for the JVM to call its main() method...

Although a main() method must be public, the class it is declared in doesn't have to be public. A private nested class can have a main() method, for example, the following code prints Hello when it is run with the command java Test$Nested

class Test {
	private static class Nested {
	   public static void main(String args []) {
     	   System.out.print("Hello");
      }
    }
}

[Campbell Ritchie]

That is a special case; because you are using the JVM to access that nested class, the usual restrictions on access to private members can be sidestepped.