A resposta de @Nikita Rybak tem bons pontos, mas falta de detalhes, eu não posso simplesmente pegar a ideia sem pensar profundamente, o seguinte é o que pensei e agora devo entender completamente o motivo.
Quatro modificadores de acesso, suponha que o 1º nível seja público e o 4º nível seja privado (com base nesta tabela em sequência). A primeira coisa que devemos saber é por que a classe não pode ser definida como privada no nível superior.
Portanto, se "private class foo" (um membro privado definido, isto é, a própria classe é um membro) permitir, qual é a externa (que contém o membro)? Escopo do arquivo? Não, o arquivo externo é inútil porque até mesmo várias classes em um único arquivo serão compiladas em arquivos de classe separados. Portanto, o exterior é um pacote . Mas o modificador de acesso padrão de terceiro nível já significa "pacote privado ". Portanto, o modificador de acesso privado de 4º nível não será usado / permitido.
Mas a classe privada aninhada é permitida porque o externo direto é a classe, não o pacote, por exemplo :
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
E se a "classe protegida foo" permitir? A principal característica protegida é a subclasse, então o (pacote) externo DEVE (devido ao escopo atualizado, mas ainda é opcional) fornecer estilo de subclasse , ou seja, sub-pacote, ou package A extends package B, mas não sabemos tal coisa. Portanto, protected não pode usar todo o potencial (o escopo principal abrange toda a subclasse) no nível superior em que o externo é o pacote (ou seja, não existe tal sub-pacote), mas protected pode usar todo o potencial na classe aninhada em que o externo é a classe ou seja, pode ser uma subclasse) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Observe que o dito acima "não pode usar todo o potencial" devido ao fato de não poder atingir toda a subclasse simplesmente porque nenhuma subclasse externa, isso significa que realmente protegido pode ser permitido , é apenas uma questão de escolha para evitar duplicar o trabalho do pacote -private se externo não for capaz de subclasse , veja abaixo.
Minha confusão é causada principalmente pela famosa tabela em https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Se o 1º nível (público) e o 3º nível (pacote privado) são permitidos, como o 2º nível intermediário (protegido) não é permitido?
subclasse de suporte público tão fácil de enganar. A maneira correta de ler esta tabela é
subclasse de suporte público se o externo tiver recurso de subclasse
O mesmo engano se aplica a package-private, package-private não suporta subclasse ( N na célula) não significa que o conceito de subclasse se aplica a outer.
Isso significa que devemos ignorar a coluna Subclasse se o recurso de subclasse não estiver disponível em externo:
Como podemos ver agora, tanto protected quanto package-private estão no mesmo nível agora ( YYN ), sem mais confusão sobre por que o nível intermediário não é permitido. No geral, o Java escolhe apenas pacote privado em vez de protegido para evitar confusão ( é apenas uma questão de escolha , mas a característica principal protegida é a subclasse, então pacote privado é superior), e o resultado , apenas 2 modificadores de acesso permitidos no nível superior:
No nível superior - público ou privado de pacote (sem modificador explícito).