Question sur la hiérarchie des interfaces

Tu peux tester avec la méthode isAssignableFrom comme je l'ai fait tout à l'heure.

A a = new A(); // check(A.class, A.class); // A x = y; is valid when y is a A
I a = new A(); // check(I.class, A.class); // I x = y; is valid when y is a A
A a = new I(); // check(A.class, I.class); // A x = y; is invalid when y is a I

Remarque : j'ai bien mis que le dernier est invalid, d'une part new I() n'a pas de sens car I est une interface et que new est un constructeur d'objet (il s'applique donc à une classe), d'autre part il n'y a rien qui lie I avec A, la relation se fait dans un seul sens (A est un I, mais I n'est pas forcément un A).

En revanche si tu es sûr que ton objet I est un A (car il peut l'être) tu peux le forcer mais il faut faire un cast explicite.

I a = new A();
A b = (A) a;

"Pourtant tu me dis que la notion de supertype existe"
J'ai dit que "ce terme n'existe", je n'ai jamais entendu parlé de "supertype" ça ne veut rien dire. Par contre la notion existe bien sûr, c'est de l'héritage multiple.

Si tu veux une photo pour preuve de ce qu'il y a écrit dans ma bible c'est comme tu veux.

"Comprends tu si je te dis que I est un type de A? <== c'est mieux ? "
Ce n'est pas à moi de comprendre, moi je sais ce qu'il en est.

Et non, ce n'est pas mieux (ni pire, je ne fais pas un classement...)
On peut dire que I est un type, que A est un type, mais il n'y a pas de hiérarchie entre les types. Le type c'est ce qui définit une variable. On peut avoir un type primitif (int, double, char, etc.) on peut avoir des classes ou des interfaces comme type.
Mais il n'y a pas de hiérarchie dans les types. Par contre il y a des relations d'héritage entre les classes et les interfaces. On peut dire que A implémente I, mais il n'y a pas de raison de dire que I est un type de A, de même qu'on peut dire que String hérite de Object mais pas que Object est un type de String.

Mais ce serait dommage de rentrer dans une guerre de lexique. Je ne me bats pas contre Cyrille Herby, je ne le connais pas, je n'ai jamais lu son tutoriel (même si je le connais de réputation puisque bon nombre de questions sur le forum consiste à lui trouver une alternative), mais puisque tu as une question, j'essaye d'y répondre de la manière la plus concrète possible.
Et il me semble que la méthode isAssignableFrom est la meilleure réponse qu'on puisse te donner. Elle permet de vérifier si pour deux types X et Y on peut faire l'affectation x = y (avec x de type X et y de type Y), ce qui n'est possible que si Y = X, Y extends X, ou Y implements X (ou bien sûr par récursivité Y extends Z avec Z extends X ; Y extends Z avec Z implements X ; Y implements Z avec Z extends X ; etc.)

class B extends A {
... // le type A est un supertype du type B. Le type B est un sous type du type A.
}

A et B ne sont pas des types, ce sont des classes (programmation objet), les types sont portés uniquement par des variables (programmation impérative).

Puisque B extends A on peut avoir :

B y = new B(); // y est un objet de la classe B
A x = y; // x est une variable de type A

Quelles différences cela fait ? Dans le code on ne peut utiliser que les méthodes du type de A, alors même que l'objet y peut théoriquement de méthodes supplémentaires spécifiques à la classe B.
C'est encore plus flagrant quand on prend une interface comme type, dans ce cas la variable ne peut être manipulée que pas les quelques méthodes de l'interface.

Il faut donc bien distinguer les notions de types, de classes et d'interfaces, c'est pour ça que je ne suis pas d'accord pour parler de "super-type". Dans ton cas "class B extends A" on pourra parler de super-classe, aucun problème là dessus,et avec "class C extends B", A sera une super classe de C aussi.