Non initialisé int vs entier

Question

J'étais en train d'étudier mon Java en préparation d'un examen et j'ai rencontré une sorte de problème avec des valeurs int/Integer non initialisées. Supposons que j'initialise un objet de la classe A. A a = new A();

class A 
    { 
     int x; 
     Integer y; 
     static int z; 
     static Integer z2; 
     public A(){} 
    } 

J'ai essayé cela dans un compilateur et a obtenu les résultats

a.x == 0; true 
a.x == null; Static Error: Bad type in comparison expression 
a.y == 0; java.lang.NullPointerException 
a.y == null; true 
a.z == 0; true 
a.z == null; Static Error: Bad type in comparison expression 
a.z2 == 0; NullPointerException 
a.z2 == null; true 

De plus, j'ai essayé quelques plus initialisées comparaisons int/interger dans un volet interactions pour voir si j'obtenir des résultats différents si mon x, y n'étaient pas des variables d'instance de classe comme elles sont ci-dessus.

int x; 
Integer y; 
x == 0; true 
x == null; Static Error: Bad type in comparison expression 
y == 0; java.lang.NullPointerException 
y == null; true 

Cependant, mes demandes de professeur dans une conférence que les valeurs doivent être les suivantes:

x == 0; Uninitialized 
x == null; Undefined 
y == 0; java.lang.NullPointerException 
y == null; Uninitialized 

Maintenant, je ne veux pas douter celui qui écrit l'examen, mais qui x == 0 et y == null la valeur de vérité est correcte? Une explication sur pourquoi serait très appréciée, merci.

Answer 1

• a.x == 0 - vrai parce que la hache a une valeur par défaut de 0.
• a.x == null - Comme indiqué, il s'agit d'une erreur de compilation. Cela résulte de §15.21.3: "Une erreur de compilation survient s'il est impossible de convertir le type de l'un ou l'autre opérande au type de l'autre par une conversion de conversion (§5.5)." Le type null n'est pas convertible en un nombre.
• a.y == 0 - Ceci essaie de déballer a.y, qui est null, donc il lance une exception NullPointerException. Contrairement à ce qui précède (qui a une valeur littérale nulle), le compilateur n'essaie pas de comprendre lors de la compilation que a.y sera null.
• a.y == null - Encore une fois, vrai parce que a.y est initialisé à null
• a.z == 0 - Identique à a.x (sauf statique)
• a.z == null - Identique à a.x (sauf statique)
• a.z2 == 0 - Identique à a.y (sauf statique)
• a.z2 == null - Identique à a.y (sauf statique)

Le problème avec le volet des interactions est que c'est à l'EDI de savoir comment l'implémenter. Si x et y sont des variables locales (non initialisées), les quatre dernières comparaisons échoueront à se compiler.

Answer 2

valeurs Java de types simples comme int/long ne peut pas être nulle de sorte qu'ils sont initialisés par 0.

Answer 3

EDIT: les variables locales non initialisées ne peuvent pas être utilisés.

Outre les habitants:

est égale à 0. int non initialisées

Entier non initialisées est égal à zéro.

Entier est un objet. Les objets unitialisés sont nuls.

int est un type primitif. Les spécifications linguistiques définissent sa valeur est non initialisée 0.

Answer 4

int x; 
Integer y; 
x == 0; true. because x is initialized to 0 by JVM 
x == null; Static Error: Bad type in comparison expression 
y == 0; java.lang.NullPointerException 
y == null; true, because y is uninitialized 

Answer 5

Tous les objets/variables dans une classe sont initialisés aux valeurs par défaut lorsqu'un objet est instancié.

thats la raison, les variables à l'intérieur de la classe ont les valeurs suivantes:

... et le reste va sur la même manière. J'espère que ma réponse est utile !!!

Answer 6

En Java, les variables de classe (statiques), les variables d'instance (celles de votre exemple) et les composants de tableau reçoivent des valeurs par défaut. D'autre part, les variables locales doivent recevoir des valeurs explicitement et ne pas avoir de valeurs par défaut.

Pour plus de détails, voir §4.12.5.

Answer 7

Celui-ci m'a buggé avant puisque les descriptions et le comportement semble un peu incohérent. Si vous regardez le language specification dans section 4.12.5 il y a une section qui décrit ceci et jive avec ce que vous avez observé le compilateur faisant.

La raison pour laquelle je pense que ceci est parfois confus est que d'autres publications que j'ai lues de Sun ("Core Java 2" par exemple) décrivent le comportement indiqué par votre prof.Et dans une autre variante, j'utilise NetBeans qui permet l'utilisation de primitives non initialisées mais signale l'utilisation d'objets non initialisés; Je ne suis pas sûr que ce soit un compilateur ou un choix IDE.

[EDIT: après avoir examiné un des postes, je crois que cette confusion ne découle du comportement différent pour les variables locales contre les champs.]

Answer 8

Cette question a été posée tout à l'heure, et il y a des réponses correctes fournies, cependant, je pense qu'elles peuvent être un peu élargies.

Je voudrais citer quelques lignes de la page des tutoriels officiels. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

Les champs qui sont déclarés mais non initialisées seront fixés à un défaut raisonnable par le compilateur

Les variables locales sont légèrement différentes; le compilateur n'attribue jamais de valeur par défaut à une variable locale non initialisée. L'accès à une variable locale non initialisée entraînera une erreur de compilation.

Les primitives Java ont une valeur qui est un nombre. (Ce n'est pas aussi simple et je vous invite à en lire plus.) Une valeur pour un objet est une référence d'où il est possible de trouver le contenu de l'objet.

La valeur par défaut d'une primitive est essentiellement 0, alors que la valeur par défaut d'un objet est null. (quand non initialisé et quand un champ)

Dans votre exemple, vous essayez de comparer "0 à 0, null à null et null à 0".

Le fait est: null! = 0.

• 0 = une valeur numérique ne représentant rien.
• null = un littéral pour représenter une référence non existante. (Vous pouvez voir What is null in Java? pour plus de détails sur null)

Pour votre information: Je crois que cette question a été répondue par Matthew Flaschen splendidement déjà, je voulais simplement ajouter des informations supplémentaires pour ceux qui sont intéressés.