java.lang.Object.equals() et les entiers

Saviez-vous que, parfois, en informatique, 10 n’était pas égal à 10, ni même à 2 ? En tout cas, c’est comme cela que peut être amené à raisonner Java avec les entiers.

Prenons le code suivant :

boolean result = (10 == 10);

La variable result est bien égale à true.

Mais avec le code suivant :

Integer entier = new Integer(10);
Long entierLong = new Long(10);
boolean result = entierLong.equals(entier);

La variable result est égale à false. Etonnant, non ?

En fait, pas tant que ça. Java stocke les entiers sur 32 bits et les entiers longs sur 64. Il va de soit qu’avec cette différence un entier long peut stocker beaucoup plus de valeurs différentes qu’un entier « normal ». Cette différence de plage de valeurs prend tout son sens si l’on considère le fait que Java ne gère que les entiers signés.

En effet, pour un entier signé 32 bits :

1111 1111 1111 1111 1111 1111 1111 1111

équivaut à -1.

Mais, pour un entier signé 64 bits :

0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 1111

équivaut à 4 294 967 295.

Si les entiers étaient non signés, il serait alors possible d’appliquer la comparaison en cas de types différents sur les 32 premiers bits. Mais voilà, ce n’est pas le cas. Alors attention lors que vous utilisez des objets Integer et Long dans des conteneurs de type Collection ou List avec la fonction contains(). Vous pourriez avoir des surprises.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s