A resposta é: varpode representar qualquer coisa que o compilador possa raciocinar sobre como um tipo, mesmo os não-denotáveis: Ele permite que você adie a questão. O erro que você acabou tendo existe desde antes da introdução do varque prova que isso não é um problema com var especificamente; é um efeito pretendido (mas um tanto estranho) que corresponde à especificação de linguagem Java.

Vamos entrar em detalhes e decompô-los. Mas primeiro:

Lembrete – GPT é inútil

GPT é uma ferramenta que produz uma resposta autoritativa. Como em, ele vai continuar tentando responder sua pergunta até que algo apareça que pareça autoritativo. Pode ser um monte de besteira completa e neste caso, de fato é. Geralmente pedir ao GPT por respostas objetivas é uma ideia muito ruim: Claro, para perguntas simples parece magicamente incrível, mas então - era uma pergunta simples. Existem muitas maneiras de obter a resposta para uma pergunta simples. Não é para isso que você deve otimizar - seriam respostas para perguntas complexas. E o GPT é muito ruim nisso. No sentido de que você não consegue dizer. Ele lhe dará uma resposta que soa muito bem.

Lembre-se disto: Perguntar a um GPT sobre questões esotéricas de linguagem é ridículo. Nunca faça isso.

Não vou abordar mais as respostas do GPT. Elas são inúteis (possivelmente erradas, possivelmente não erradas. Qualquer dica que elas dão pode ser relevante, ou não. Portanto, inúteis).

Tipos não denotáveis

É uma questão de linguagem/compilador, então nos referimos à fonte, o JLS:

JLS21 §14.4.1 :

Se o LocalVariableType for var, então deixe T ser o tipo da expressão inicializadora quando tratada como se não aparecesse em um contexto de atribuição e fosse, portanto, uma expressão autônoma (§15.2). O tipo da variável local é a projeção ascendente de T com relação a todas as variáveis ​​de tipo sintético mencionadas por T (§4.10.5).

E observe também este esclarecimento na caixa de exemplo:

Observe que algumas variáveis ​​declaradas com var não podem ser declaradas com um tipo explícito, porque o tipo da variável não é denotável.

A última parte está implícita na definição real (pois a definição não declara em nenhum momento que o tipo que o compilador infere varprecisa ser denotado, portanto você deve inferir que ele não precisa ser; a nota na caixa de exemplo destaca isso).

E é essencial para entender o que está acontecendo aqui. Aqui está um exemplo de uso de tipo não denotável que é mais fácil de seguir do que o que esta questão encontrou:

class Example {
  public static void main(String[] args) {
    Object o = new Object() {
      void test() {
        System.out.println("HELLO!");
      }
    };
    o.test(); // compiler error.

    var p = new Object() {
      void test() {
        System.out.println("HELLO!");
      }
    };

    p.test(); // works!!
  }

  void asAReminder() {
    new Object() {
      void test() {
        System.out.println("This has always worked"); 
      }
    }.test();
  }
}

Cole o acima em um arquivo, compile-o - erro na linha que diz 'compiler error'. Marque-o, compile novamente, execute-o - funciona bem.

O que é bizarro no sentido de que não há nada que você possa substituir varque faça isso funcionar . O que está acontecendo é que o ptipo de é inferido como o tipo da classe local anônima e esse tipo tem um test()método . Isso sempre fez parte do Java (bem, desde a versão 1.2 ou algo assim, décadas atrás neste ponto), só que varagora permite que você declare variáveis ​​locais com esse tipo. O asAReminder()método mostra isso; que o código 'funciona' (compila e roda como você esperaria) em qualquer versão Java das últimas 2 décadas.

Portanto, varpode denotar InnerParentmuito bem aqui. Não é 'denotável' - se você literalmente substituir varem seu exemplo por InnerParentele falharia na compilação porque InnerParentnão é acessível, mas varmeramente representa o tipo da expressão da maneira como o compilador a trata. E o compilador tem que suportá-lo . Afinal, isso é perfeitamente legal:

Object o = new Child.InnerChild().self();

O compilador terá que lidar com o fato de que a expressão atribuída oaqui é InnerParent ( self()afinal, a definição de diz isso) e, portanto, terá que descobrir no contexto que isso é aceitável.

Nós também podemos provar isso!

Prova de que isso não tem nada a ver comvar

Tente substituir sua maindefinição pela seguinte:

public class Main {
    public static void main(String[] args) {
        new Child.InnerChild().self().getClass();
    }
}

Esse código não será compilado, com exatamente o mesmo erro:

Object.getClass() is defined in an inaccessible class or interface

Em outras palavras, no Java 8 (que não suporta var nada - varcomo um recurso foi adicionado no Java 10) podemos ter o mesmo conceito: Uma expressão que é, ela própria, legal, e cujo tipo não é acessível no contexto em que a escrevemos. Ela 'funciona', mas o tipo é extremamente venenoso: Se você 'tocar' nela, quase tudo que você fizer com ela será um erro do compilador; mesmo invocando finalmétodos herdados diretamente do obviamente acessível java.lang.Object. Praticamente a única coisa que você pode fazer com eles é tratá-los como um tipo acessível primeiro (por meio de cast ou atribuição a uma variável) ou passá-los para outro método na íntegra.

varapenas permite que você adie a solução.

var innerChild = new Child.InnerChild().self();simplesmente não viola nada do que a Especificação da Linguagem Java diz.

Na Seção 6.6 , é dito que o controle de acesso é aplicado quando você usa um nome qualificado .

Nomes qualificados são um meio de acesso a membros de pacotes, classes, interfaces, parâmetros de tipo e tipos de referência. Quando o nome de tal membro é classificado de seu contexto (§6.5.1) como um nome de tipo qualificado (denotando um membro de um pacote, classe, interface ou parâmetro de tipo) ou um nome de expressão qualificado (denotando um membro de um tipo de referência), o controle de acesso é aplicado.

Você não usou o nome InnerParentaqui, então as regras de controle de acesso não são aplicadas.

Alguns tipos de expressões também impõem controle de acesso. Por exemplo, uma chamada de método em uma expressão primária precisa garantir que o método que está sendo chamado seja acessível. É por isso que a chamada innerChild.getClass()produz um erro. Especificamente, esta cláusula proíbe o acesso:

Um membro (classe, interface, campo ou método) de uma classe, interface, parâmetro de tipo ou tipo de referência, ou um construtor de uma classe, é acessível somente se (i) a classe, interface, parâmetro de tipo ou tipo de referência for acessível, e (ii) o membro ou construtor for declarado para permitir acesso: [...]

InnerParentnão é acessível, então seu método getClasstambém não é acessível.

Veja as letras pequenas antes do cabeçalho da seção 6.6.1 para mais informações.

varnão é um açúcar sintático simples que é simplesmente substituído/reescrito com o nome do tipo da expressão no RHS. A expressão no RHS pode nem ter um nome (por exemplo, classes anônimas) ou pode não ter um tipo (por exemplo, expressões lambda e referências de método). O tipo de uma varvariável é especificado em 14.4.1

Se o LocalVariableType for var, então deixe T ser o tipo da expressão inicializadora quando tratada como se não aparecesse em um contexto de atribuição e fosse, portanto, uma expressão autônoma (§15.2). O tipo da variável local é a projeção ascendente de T com relação a todas as variáveis ​​de tipo sintético mencionadas por T (§4.10.5).

Ao escrever var, você realmente não está usando o nome de InnerParent.