JRL a écrit:
Non ce n'est pas, ...
Comme souvent, cela dépend d'où vous le regardez, de qui vous croyez le plus.
Selon le JLS, oui, c'est le cas . Surtout si vous reformulez la question comme suit: «Le nulllittéral est-il de type Object?». En plus de JLS 4.1 cité par Michael Borgwardt ci-dessus:
Voir JLS 3.10.7 :
Un littéral nul est toujours de type nul.
et JLS 4.10 :
Les sous-types d'un type T sont tous les types U tels que T est un supertype de U, et le type nul.
ou JLS 4.10.2 :
Les supertypes directs du type nul sont tous des types de référence autres que le type nul lui-même.
[Souligné par moi.]
Selon le compilateur d'Eclipse 2019-09, ce n'est pas :
true.toString(); // Cannot invoke toString() on the primitive type boolean
null.toString(); // Cannot invoke toString() on the primitive type null
Selon OpenJDKs 12.0.1, javac c'est :
true.toString(); // error: boolean cannot be dereferenced
null.toString(); // error: <null> cannot be dereferenced
Où les chevrons impliquent qu'il nulls'agit d'un type autre que primitif. Et selon JLS 4.1 :
Il existe deux types de types dans le langage de programmation Java: les types primitifs (...) et les types de référence (...).
si ce n'est pas l'un c'est l'autre.
Claudiu a écrit:
null est un peu moche.
Au contraire, nullc'est beau. Que suggéreriez-vous plutôt comme valeur par défaut pour une variable de type référence? Une combinaison de bits arbitraire? Bienvenue à la violation d'accès ou, pire encore, à l'enfer du pointeur!
Joachim Sauer a écrit:
null est un type et une valeur.
Il y a en fait trois éléments en conjonction avec null (voir aussi JLS 3.10.7 ):
- Le type nul (autrement sans nom) .
- Le
null littéral .
- La valeur de référence nulle . (Communément abrégé en valeur nulle ou simplement null .)
(1) Notez que, selon JLS 4.10.2 cité ci-dessus, le type nul utilise l'héritage multiple non seulement pour les interfaces mais aussi pour les classes. Ce que nous savons tous n'est pas possible pour nous, les programmeurs d'applications.
(2) Le littéral nul pourrait être imaginé comme une variable définie comme:
JVM_global final null_type null = new null_type();
Notez également JLS 3.9 :
Une variété de séquences de caractères est parfois considérée, à tort, comme des mots-clés:
nulln'est pas un mot-clé, mais plutôt le littéral nul ( §3.10.7 ).
Concernant null instanceof <any type>
Avec JLS 4.10.2 à l'esprit («le type nul est un sous-type de chaque type») null instanceof <any type>devrait être supposé être évalué true, n'est-ce pas? À première vue, oui, mais JLS 15.20.2 donne la réponse insight:
[...] le résultat de l' instanceofopérateur est truesi la valeur de RelationalExpression n'est pasnull [...]. Sinon, le résultat estfalse .
[Souligné par moi.]
Demandez-vous ce qui a le plus de sens (du point de vue d'un programmeur d'application):
Donner falseet donc indiquer qu'une expression de référence n'est pas d'un type qui nous est exposé, c'est-à-dire indiquer qu'elle ne fait référence à rien d'utile pour nous
ou donner true, nous informant ainsi que l'expression évalue à une référence spéciale, la référence nulle , référençant un "objet" dont nous ne savons même pas s'il existe et qui est du type nul spécial qui n'a pas de nom, n'est pas exposé à us mais via le littéral nul , est-ce qu'un sous-type de n'importe quel type incluant l'héritage multiple et doit être ignoré de toute façon? Prenons également l'exemple le plus pratique:
class Car implements Vehicle {
...
Vehicle car = null;
...
boolean b = car instanceof Car; // True? There's not even an instance
... // which could be of type Car.
Ce qui conduit également à:
Pourquoi n'est-ce instanceofpas une bonne façon de dire quelque chose à propos nullde l'objet de s?
Ça ne s'appelle instanceofpas sameorsubtypeof. Cela signifie que nous comparons le type d'une instance avec un type, pas deux types. Cela nullsignifie maintenant : «Il n'y a pas d'instance» et s'il n'y a pas d'instance, il n'y a pas de type d'instance. Il est évident que ne rien comparer à quelque chose est censé mener false.
Ou dans un exemple du monde réel "plus":
- J'ai entre les mains une photo en taille réelle d'une pomme ( = type de référence ) avec »Big Apple« ( = nom du type de référence ) écrit dessus.
- Il y a une table ( = tas ) devant moi.
- S'il y a une pomme ( = instance ) sur la table, un cordon ( = référence ) y est connecté.
- Je tiens l'autre extrémité de ce cordon dans ma main ( = variable de référence ).
- Je trace la pomme le long du cordon et la compare avec ma photo ( = instanceof ).
- Si la pomme est de la même taille ou plus grande que l'image, l'écriture «Big Apple» lui s'applique ( = vrai ).
- S'il est plus petit, alors non ( = faux ).
- S'il n'y a pas de pomme sur la table (= aucune instance ) et, par conséquent, aucun cordon n'existe ( = null ) l'écriture ne s'applique pas non plus ( = false ). Parce que: Aucune pomme n'est-elle une grosse pomme? Non ce n'est pas.
Comme le résume Michael: "nul est spécial" en effet.