Циклическое наследование интерфейсов

Нет, но расширение интерфейса — это способ разделения соглашения. Помните, что интерфейс — это соглашение о реализации набора методов.

public interface A extends B {
    public void myMethod();
    public void myOtherMethod();
}

Вы говорите, что интерфейс A определяется этими методами и всеми методами интерфейса B. Теперь, если интерфейс B говорит..

public interface B extends A {}

вы говорите, что интерфейс B определяется методами интерфейса A. Ну что определяет интерфейс A. Пара методов и интерфейс B. А что определяет интерфейс B? Интерфейс A, который определяется парой методов и интерфейсом B! Видите, куда это идет?

Не имеет логического смысла допускать это.

Теоретических трудностей, вероятно, нет, но это создало бы ненужные сложности. Несколько названий:

• В настоящее время обход интерфейсов классов (через рекурсивные вызовы Class.getInterfaces()) гарантированно дает конечный результат, возможно, с повторениями, но тем не менее. Например, такой код действителен:

  private static void fillInterfaces(Class<?> clazz, Set<Class<?>> set) {
      if(clazz == null) return;
      for (Class<?> iclass : clazz.getInterfaces()) {
          set.add(iclass);
          fillInterfaces(iclass, set);
      }
      fillInterfaces(clazz.getSuperclass(), set);
  }
  
  public static Set<Class<?>> getAllInterfaces(Class<?> clazz) {
      Set<Class<?>> result = new HashSet<>();
      fillInterfaces(clazz, result);
      return result;
  }
  

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

• В настоящее время (в Java-8) интерфейс может также определять реализацию по умолчанию для своего родительского интерфейса, при необходимости заменяя родительскую реализацию. Например:

  interface A {
      default public String getX() {return "A";}
  }
  
  interface B extends A {
      default public String getX() {return "B";}
  }
  
  static class C implements A, B {} // ok, C.getX() returns "B"
  

  Если сейчас A extends B, то A выигрывает:

  interface A extends B {
      default public String getX() {return "A";}
  }
  
  interface B {
      default public String getX() {return "B";}
  }
  
  static class C implements A, B {} // ok, C.getX() returns "A"
  

  А если и A extends B, и B extends A? Кто победит? Что new C().getX() напечатает? Или это должен быть новый тип ошибки компиляции?

В целом кажется, что такая функция принесет больше проблем, чем пользы.

См. Спецификацию языка Java 9.1. 3 Суперинтерфейсы и субинтерфейсы:

Интерфейс I зависит от ссылочного типа T, если выполняется любое из следующих условий:

• Я напрямую зависит от Т.

• I напрямую зависит от класса C, который зависит от T (§8.1.5).

• I напрямую зависит от интерфейса J, который зависит от T (рекурсивно используя это определение).

Это ошибка времени компиляции, если интерфейс зависит от самого себя.

Если циклически объявленные интерфейсы обнаруживаются во время выполнения, когда интерфейсы загружаются, выдается ошибка ClassCircularityError (§12.2.1).

Что касается почему, мне нравится комментарий Энди Тернера:

Если Foo extends Bar, то каждый экземпляр Foo также является Bar. Если Bar extends Foo, то каждый экземпляр Bar также является Foo. Если бы оба условия были истинными, то единственным способом удовлетворения этих двух условий было бы условие Foo == Bar.