Why can't a class be defined as protected?

Question

I know this is a stupid question, but I still have a doubt that needs to be addressed.

My question is: why can't we define the class as protected ?

I know we cannot, but why? There must be some specific reason.

Answer 1

Because it does not make sense.

A protected member of a class (method or variable) is similar to closing a package (default visibility), except that it can also be accessed from subclasses.
Since Java does not have a concept such as “subpackage” or “package inheritance”, declaring a class or package-private would be the same.

You can declare nested and inner classes as protected or private.

Answer 2

As you know, for access to the package level and protection the package level is used, as well as classes that are different from the package, but which extends this class (it is indicated here that you can expand the class only if it is visible!). So to speak:

• a protected top-level class will be visible to classes in its package.
• now makes it visible outside the package (subclasses) a bit confusing and complicated. What classes should be allowed to inherit our protected class?
• If a subclass is allowed for all classes, it will look like a shared specifier.
• If not, then this looks like a default value.

Since there is no way to restrict this class to a subclass of only a few classes (we cannot restrict a class that is inherited by only a few classes from all available classes in / outside the package), there is no benefit to the security access specifiers for top-level classes. Therefore, this is not permitted.

Answer 3

 public class A { protected class B { } } 

Answer 4

The definition of a protected field makes this field available both inside the package and outside the package only through inheritance (only inside the child class).

Therefore, if we are allowed to make a class protected, we can very easily access it inside the package, but to access this class outside the package, we first need to expand the object in which this class is defined, which is its package.

And since the package cannot be extended (it can be imported), defining a protected class will again make it closed to the package, which is similar to defining it by default, which we can already do. Therefore, there is no point in defining a private class, it will only make things ambiguous.

For more information, read Why an external Java class cannot be private or protected.

Answer 5

Of the 4 access modifiers, the public, private, secure, and default class can only have a public and default modifier.

If you have an open class, you can use it wherever you want, which is very simple. You can import it into any package and start using it.

But, if you have a class without a modifier / by default, you cannot even import it into another package. For example, you have a class: as DefaultClass.java

 package home; class DefaultClass{ .. } 

and the other class is TestingIt.java in another package.

 package office; import home. 

The moment you try to import home.DefaultClass into the above code, you will realize that our DefaultClass cannot be imported. This is not visible on packaging outside the home. We cannot import it into this TestingIt.java file. Why not? because default = is limited to its own package.

And now to your question "why can't a class protect an access modifier?" I think that is probably because it will not be different from the default / no modifier class. Even if a “protected class” was possible, you will not be able to import it into another package, like a “default class / without modifier”.

You can use them in one package, but as soon as you import them, they will work exactly the same in one package. Therefore, with regard to access modifiers for classes, they are protected both by default and by default.

Answer 6

@ Nikita Rybak's answer has good points, but lack of details, I can’t just get an idea without thinking deeply about myself, the following is what I thought, and now I have to fully understand the reason.

Four access modifiers, suppose 1st level is public and 4th level is private (based on this table in sequence). The first thing we should know is why a class cannot be defined as closed at the top level.

So if "private class foo" (a specific private member, i.e. the class itself is a member) allows what is external (which contains the member)? File size? No, an external file does not make sense, because even several classes in one file will be compiled into separate class files. So the external is the packaging . But the default access modifier of level 3 already means "private package ". Thus, the level 4 private access modifier will not be used / allowed.

But a nested private class is allowed because the direct external is the class, not the package, for example :

 class PrivateNestedMain { private static class Inner { public static void main(String[] args) { System.out.println("Hello from Inner!"); } } } 

But what if the "protected class foo" allows? The protected main characteristic is the subclass, so the external (package) MUST (due to volume, but still not necessary) provide the style of the subclass , i.e. the subpackage, or package A extends package B , but we don’t know anything like that. Thus, the protected cannot use the full potential (the main scope of the subclass) at the top level, which is the package outside (i.e., such a subpacket does not exist), but the protected can use the full potential in the nested class, which is the class external (t .e. may be a subclass) :

 class ProtectedNestedMain { protected static class Inner { public static void main(String[] args) { System.out.println("Hello from Inner!"); } } } 

Please note that the above “cannot use the full potential” because it cannot reach the whole subclass just because the external subclass cannot be resolved , that is, it is actually protected , it’s just a matter of choice, to avoid duplication of the package’s work-private. if external is not subclass , see below.

My confusion is mainly caused by a famous table at https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :

If the 1st level (public) and the 3rd level (private package) are allowed, then how, in fact, the intermediate level of the 2nd (protected) is not allowed?

Public support for a subclass is so easy to mislead. The correct way to read this table

public helper subclass if the outer has a subclass property.

The same misleading application to a private package, a private package does not support a subclass ( N in a cell) does not mean that the concept of a subclass is applied externally.

This means that we should ignore the Subclass column if the subclass function is not available in external:

As we see now, both the protected and closed packages are at the same level ( YYN ), there is no more confusion as to why the intermediate layer is not allowed. In general, Java selects only a closed package, not a protected one, to avoid confusion ( this is just a matter of choice , but the main characteristic of a protected object is a subclass, so the package’s privacy is higher), and as a result , only 2 access modifiers are allowed at the top level:

At the top level, public or package-private (without an explicit modifier).

Answer 7

Protected does not look like public. The protected one has access at the package level plus access to them outside the packages only by inheritance. If a class says A outside the INHERITS package, a class from another package (with a protected method using INHERITANCE), it can access methods of this class B that have protected methods, but subclasses derived from this class, i.e. A cannot access protected methods .. the opposite happens to public.

Example:

 package 2; class B { protected void method1() { } } package 1; import 2.B; class A extends B { //can access protected method } class C extends A { //can't access the protected method } 

Answer 8

behavior "protected" = behavior "default" + "use it in any subclass in any package."

In any case, we have the default access modifier for the class, the only advantage we can get from the protected access modifier is the following: - using it in any package through a subclass. But for a subclass, the visibility of the parent “protected” class would be private. Therefore, it may not be available. Basically, if you have a top-level protected class, the outer class cannot access by subclassing it. Thus, protecting a top-level class is pointless.

Answer 9

Protected : SEE only for package level *.

the class is defined as protected ---> it cannot be extended from an external package (not visible).

And if it cannot be expanded, then it makes no sense to keep it protected, because then it will become the default access that is allowed.

The same applies to private defined classes.

Note. Nested or inner classes can be defined as protected or private.

* : Study the protected keyword, for this answer I have made it short.

Answer 10

The answer from @ Akash5288 didn't make any sense to me:

If all classes are allowed to subclass, then this will look like an open access specifier.

Since there is no way to limit the subclass of this class to only a few classes (we cannot limit the inheritance of a class to only a few classes from all available classes in the package / outside the package), no security access specifiers are used for higher-level classes. Therefore, this is not permitted.

Then you can apply the same logic to protected methods and variables, they are also "similar to public." All classes outside the package can extend our public class and use its protected methods. Why is the restriction of methods and variables to extended classes normal, but the whole class not? “Like the public” is not the same as the public. My interpretation is that resolving a protected class is perfectly fine, as are protected methods.

The answer "You cannot extend a class that you cannot access / see" is more logical.

Answer 11

What makes sense in this question is that the JVM is written in C (Sun JVM) and C ++ (oracle JVM), so at compile time we are going to create .class files from our java file, and if we declare a class with a protected key word, then it will not be available to the JVM.

The answer to why the protected class will not be available to the JVM is that the protected fields are available in the same package or in another package only through inheritance, and the JVM is not written in such a way that it inherits the class. Hope this satisfies this question :)

Similarly, a top-level class cannot be closed. Explanation as below:

So what happens if we define a private class, this class will be available only inside the entity in which it is defined, and in our case it is its package?

Thus, the definition of private access to a class will make it available in the same package that the default keyword already does for us, so there is no advantage in defining a private class, it will only make things ambiguous.

Answer 12

Protected means that a member can be accessed by any class in the same package and subclasses, even if they are in other packages.

Example:

 package a; class parent{ protected void p(); } package b; import ap; class child extends parent{ //you can access method which is protected in the parent in the child } class another extends child { //here you can not access the protected method }