Quero saber quantas instâncias de uma classe de membro estática podem ser criadas pela classe envolvente. Suponho apenas um, mas o seguinte extrato de Bloch não faz sentido para mim.

Citando o Java efetivo de Joshua Bloch - Item 22 *: Favorece as classes de membros estáticos do que não estáticos.

Um uso comum de classes de membros estáticos particulares é representar componentes do objeto representado por sua classe envolvente. Por exemplo, considere uma instância de Mapa, que associa chaves a valores. Muitas implementações de mapas têm um objeto Entry interno para cada par de valores-chave no mapa. Embora cada entrada esteja associada a um mapa, os métodos em uma entrada (getKey, getValue e setValue) não precisam de acesso ao mapa. Portanto, seria um desperdício usar uma classe de membro não estático para representar entradas: uma classe de membro estática privada é melhor. Se você acidentalmente omitir o modificador estático na declaração de entrada, o mapa ainda funcionará, mas cada entrada conterá uma referência supérflua ao mapa, que desperdiça espaço e tempo.

Ele afirma que o mapa cria um objeto Entry para cada par de valores-chave no mapa, ou seja, várias instâncias da classe de membro estático.

Então, minha suposição está errada! Isso significa que meu entendimento das classes de membros estáticos está errado. Todo mundo sabe como uma variável de membro estática se comporta, a sequência final estática clássica, por exemplo - há apenas uma instância do objeto.

Isso significa que uma classe de membro estática não é realmente instanciada quando o objeto envolvente é instanciado?

Bem, nesse caso, qual é o sentido do mapa usando uma classe de membro estático para o Entry? Por que não usar apenas uma interface na API? Todas as outras classes de coleções poderiam fornecer sua própria implementação.

[*] Acabei de perceber que é o item 18 da versão em PDF do livro que tenho