Discussion :

[flamant]

Bonjour,
voici un extrait de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
interface Apple {}
.....
.....
class Tangerine implements Orange {}
.....
.....
Tangerine t = new Tangerine()
System.out.print(t instanceof Apple);

Curieusement cette dernière ligne de code compile alors que t n'a rien à voir avec Apple . La raison qui est donné est qu'il pourrait y avoir une sous classe de Tangerine qui implémente Apple. D'après moi même si il y avait cette sous classe, le compilateur devrait renvoyer une erreur dans le cas décrit juste au dessus. Auriez vous une explication

[INFORMATICA2025]

Bonjour,

Explication :
le code compile (Tangerine n'est pas final, une sous-classe pourrait implémenter Apple), mais l'objet créé est un Tangerine qui n'implémente pas Apple, donc (t instanceof Apple) renvoie false.

Plus de détails :
Le compilateur Java effectue un contrôle statique basé sur les types déclarés et rejette un instanceof seulement quand il peut prouver que les deux types sont incompatibles à la compilation (par exemple si la classe testée est final et n’implémente pas l’interface). Dans votre cas, Tangerine n’est pas final : il est donc possible (du point de vue du compilateur) qu’une sous‑classe de Tangerine implémente Apple, donc l’expression instanceof est autorisée. Le fait que vous écriviez new Tangerine() ne force pas le compilateur à inférer « impossible » sauf si la classe est déclarée final (ou scellée de façon à exclure toute sous‑classe pertinente[compatible]).

Quelques cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
//Exemple 1
interface Apple {}
class Tangerine {}          // non-final --> compilateur laisse passer
Tangerine t = new Tangerine();
System.out.println(t instanceof Apple); // compile, affiche false

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
//Exemple 2
interface Apple {}
final class Tangerine {}    // final --> aucune sous-classe possible
Tangerine t = new Tangerine();
System.out.println(t instanceof Apple); // ERREUR de compilation : inconvertible types

Résumé 1 :
si la relation est prouvablement impossible à la compilation (p.ex. classe final sans sous‑classe compatible), instanceof est rejeté ; sinon il est autorisé car une sous‑classe pourrait exister au runtime.

Et voici quelques cas montrant le comportement de instanceof quand Tangerine implémente Orange.
Exemple 1 — Tangerine implémente Orange (test direct)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Exemple 1
interface Orange {}
class Tangerine implements Orange {}
Tangerine t = new Tangerine();
System.out.println(t instanceof Orange); // true

Exemple 2 — test d'une interface non liée (compile mais false à l'exécution si pas de sous-classe)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Exemple 2
interface Apple {}
interface Orange {}
class Tangerine implements Orange {}   // non-final
Tangerine t = new Tangerine();
System.out.println(t instanceof Apple); // compile (Tangerine peut avoir une sous-classe qui implémente Apple), résultat : false

Exemple 3 — classe final (le compilateur détecte l'incompatibilité)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Exemple 3
interface Apple {}
interface Orange {}
final class Tangerine implements Orange {} // final : aucune sous-classe possible
Tangerine t = new Tangerine();
System.out.println(t instanceof Apple); // ERREUR de compilation : inconvertible types

Exemple 4 — sous-classe qui implémente Apple (montrer différences runtime)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
// Exemple 4
interface Apple {}
interface Orange {}
class Tangerine implements Orange {}
class OrangeExtends extends Tangerine implements Apple {}
Tangerine t1 = new Tangerine();
Tangerine t2 = new OrangeExtends();
System.out.println(t1 instanceof Apple); // false
System.out.println(t2 instanceof Apple); // true

Résumé 2:
le compilateur autorise instanceof tant qu’il ne peut pas prouver statiquement l’incompatibilité (par ex. si la classe est final ou si les types sont manifestement incompatibles).

[flamant]

Merci de ton retour INFORMATICA2025. C'est résolu

[INFORMATICA2025]

FLAMANT, JE T'EN PRIE.

[thelvin]

On notera que techniquement, il est tout à fait possible pour un compilateur de pousser l'analyse statique jusqu'au fait de détecter que dans le cas présent, effectivement, la variable t ne pouvait pointer que vers un objet de classe réelle Tangerine, que cette classe n'implémente pas Apple, et donc qu'il est impossible que le résultat de ce instanceof soit autre chose que faux.

D'ailleurs le compilateur ne génère pas d'erreur de compilation, mais il fait un avertissement à propos du fait que l'expression est toujours fausse, c'est donc bien qu'il a pas de mal à le détecter. Des expressions alambiquées qui sont toujours fausses, ou vraies, ou qui ont toujours le même résultat qui s'écrit plus simplement, on peut considérer que ça ne sert à rien et qu'il faudrait encourager à ne pas en avoir, et donc à en faire une erreur plutôt qu'un avertissement.

Mais, le compilateur n'est pas censé faire ce qu'il veut. La technologie Java est définie par des spécifications précises et pas trop compliquées à mettre en œuvre (même si pouvoir le faire efficacement avec de la compilation just in time et un ramasse-miettes performant, ça ça devient compliqué). Et ces spécifications disent que l'analyse statique ne doit pas aller aussi loin que ça pour détecter les erreurs, on utilise la définition des types mais pas une vérification certaine du type réel des objets manipulés, ni même que ce soient vraiment des objets et pas null. Pas d'erreur pour ça, mais les compilateurs peuvent faire les avertissements qui leur chantent.

Ce n'est pas seulement une question de faciliter l'implémentation d'un compilateur, voire pas du tout. Il y a aussi le fait que quand on utilise un langage on peut vouloir tester des trucs rapidement et que le compilateur qui détecte tout le temps ce que ça ferait si on lançait un tel programme et donc refuse de le faire à la place, c'est agaçant. Il est donc choisi de ne faire une erreur, que pour les choses qui sont franchement bien établies comme des erreurs, comme des types incompatibles carrément par leur définition.