Почему я не могу сделать это / есть обходной путь для достижения этой цели:

package myPackage;

public class A {
    public class B {

    }
}

package myPackage;  

import myPackage.A.B;

public class C extends B {

}

package myPackage;

public class Main {
    public static void main(String[] args) {
        A myA = new A();
        C myC = myA.new C();
    }
}

Две ошибки компиляции

Наpublic class C extends B, No enclosing instance of type A is available due to some intermediate constructor invocation

НаC myC = myA.new C();, A.C cannot be resolved to a type

Честно говоря, я думаю, что концептуальная идея обоснована: я хочу сделать подкласс B, чтобы, когда я делаю B для A, у меня есть возможность сделать так, чтобы он имел функциональность в B или функциональность в C.

Четыре обходных пути / решения, которые яне хочу, а почему я не хочу их

«Решение: поместите С внутрь А.» Я не хочу этого, потому что, что, если я не могу изменить код для A.java (есть приложения, которые имеют это ограничение)? Что если A является частью другого API? Затем я должен создать новый файл для C, как я сделал здесь.

«Решение: поместите C в класс D, который расширяет A.» Я не хочу этого, потому что тогда C ограничивается только созданием экземпляров на экземплярах типа D. Я хочу создать класс, расширяющий B, который может быть создан навсе экземпляры типа A (есть приложения, которым это нужно). Поэтому мне нужно, чтобы C не был заключен в другой класс, как я это сделал здесь.

(Добавлено как вопрос редактирования - см. Ответ Джошуа Тейлора для примера кода) «Решение: Сделайте B статичным». Я не хочу этого, потому что что, если функциональность в B нуждается в доступе к включающему его экземпляру A (есть приложения, которым это нужно)? Поэтому мне нужно, чтобы B не был статичным, как я сделал здесь. (2-е редактирование вопроса: вы можете сделать B статичным и получить его конструктор в своем включающем экземпляре, сохранив его в защищенной переменной для доступа к его дочерним элементам, но это менее элегантно, чем принятый ответ RealSkeptic)

Удалены. См редактировать внизу.

Итак, если ваш ответ предполагает, что я делаю одно из вышеперечисленного, этоне ответ на этот вопрос, хотя это может быть полезно для других людей.

Если ваш ответ «Это просто недостаток языка Java, вы простоне может реализовать эту концептуальную идею ", это хороший ответ, и вы должны опубликовать его. Просто предупреждение: я не буду отмечать ваш ответ как принятый, если вы не правы. Если это ваш ответ, я был бы очень признателен, если у вас есть объяснение, почему введено это ограничение на язык (так называется этот вопрос).

Спасибо за любую помощь.

РЕДАКТИРОВАТЬ: ответ JoshuaTaylor вызывает действительный вариант: вы можете продлить Bанонимно и избегайте необходимости писать конструктор, как в принятом ответе RealSkeptic. Первоначально я отказался от этой идеи, потому что она не позволяет вам получить доступ к включенному в C экземпляру A через «A.this». Однако с тех пор я узнал, что в C нет включающего экземпляра A, если только он не определен в определении A как вложенный класс. Поэтому обратите внимание: ни одно из приведенных ниже решений не позволяет вам получить доступ к включающему экземпляру A, который включает в себя предка C для B, написав «A.this» в методе C. Классы могут использовать «.this» только для доступа к типам, которые они специально вложены в. Однако, если B имеет функциональность, которая обращается к включающему экземпляру A, требуется либо анонимный класс с помощью метода JoshuaTaylor, либо любой другой класс с помощью метода RealSkeptic.