La respuesta de @Nikita Rybak tiene buenos puntos pero falta de detalles, no puedo simplemente entender la idea sin pensar profundamente, lo siguiente es lo que pensé y ahora debería entender completamente la razón.
Cuatro modificadores de acceso, suponiendo que el primer nivel es público y el cuarto nivel es privado (según esta tabla en secuencia). Lo primero que debemos saber es por qué la clase no se puede definir como privada en el nivel superior.
Entonces, si la "clase privada foo" (un miembro privado definido, es decir, la clase misma es un miembro) lo permite, ¿cuál es el exterior (que contiene el miembro)? Alcance del archivo? No, el archivo externo no tiene sentido porque incluso varias clases en un solo archivo se compilarán en archivos de clase separados. Entonces el exterior es el paquete . Pero el modificador de acceso predeterminado de tercer nivel ya significa "paquete privado ". Por lo tanto, el modificador de acceso privado de 4 ° nivel no se utilizará / permitirá.
Pero la clase privada anidada está permitida porque el exterior directo es clase, no paquete, por ejemplo :
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Ahora, ¿qué pasa si la "clase protegida foo" lo permite? La característica principal protegida es la subclase, por lo que el (paquete) externo DEBERÍA (debido al alcance, pero aún es opcional) proporcionar el estilo de la subclase , es decir, el subpaquete, o package A extends package B, pero no sabemos tal cosa. Por lo tanto, protected no puede usar todo el potencial (el alcance principal es para toda la subclase) en el nivel superior en el que el exterior es el paquete (es decir, no hay tal subpaquete), pero protected puede utilizar todo el potencial en la clase anidada, que el exterior es la clase ( es decir, puede ser una subclase) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Tenga en cuenta que lo anterior dijo "no se puede utilizar todo el potencial" debido a que no puede llegar a toda la subclase simplemente porque no hay una subclase externa, eso significa que se puede permitir realmente protegido , es solo una cuestión de elección para evitar duplicar el trabajo del paquete -privado si externo no apto para subclase , ver más abajo.
Mi confusión se debe principalmente a la famosa tabla en https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Si el 1er nivel (público) y el 3er nivel (paquete privado) están permitidos, ¿cómo diablos no se permite el 2º nivel intermedio (protegido)?
subclase de apoyo público tan fácil de engañar. La forma correcta de leer esta tabla es
subclase de soporte público si el exterior tiene una característica de subclase.
El mismo engaño se aplica a package-private, package-private no admite subclase ( N en celda) no significa que el concepto de subclase se aplique en el exterior.
Eso significa que debemos ignorar la columna Subclase si la función de subclase no está disponible en el exterior:
Como podemos ver ahora, tanto protected como package-private tienen el mismo nivel ahora ( YYN ), no más confusión sobre por qué no se permite el nivel intermedio. En general, Java elige solo paquete-privado sobre protegido para evitar confusiones ( es solo una cuestión de elección , pero la característica principal protegida es la subclase, por lo que el paquete-privado es superior) y, como resultado , solo se permiten 2 modificadores de acceso en el nivel superior:
En el nivel superior: público o paquete-privado (sin modificador explícito).