Afficher une alerte en cas d'utilisation potentiellement erronée de l'opérateur ==

Bonjour,

Dans ce morceau de code :

Code:

---

1 2 3 4 5 6 7 8

Integer a = 0; Integer b = 0; while (a == b) { System.out.println("a=" + a + ", b=" + b + "\t" + (a == b) + "\t" + (a.equals(b))); a++; b++; } System.out.println("a=" + a + ", b=" + b + "\t" + (a == b) + "\t" + (a.equals(b)));

---

Je sais pertinemment qu'il faut exclusivement utiliser le .equals() sur des types de variables non primitives mais pourtant, ca m'arrive encore d'utiliser par erreur ce canonique ==

Ce qui m’énerve le plus, c'est que ce morceau de code va fonctionner jusqu'à la 128ème itération de la boucle, et ce sans erreurs, sans warnings aucun, puis ne plus fonctionner à la 129ème !

S'il ne faut pas utiliser le == sur autre chose que des primitifs, pourquoi mon IDE (NetBeans en l’occurrence) n'est pas capable de me le rappeler ?

Une idée du pourquoi et du comment ?

Merci d'avance.

Citation:

---

S'il ne faut pas utiliser le == sur autre chose que des primitifs, pourquoi mon IDE (Netbeans en l’occurrence) n'est pas capable de me le rappeler ?

---

Non, tu peux très bien utiliser le == sur autre chose que des primitifs. Il n'aura juste pas la même signification que sur les types primitifs... Je ne vois pas ce que tu veux que NetBeans te prévienne. Ca reste du code tout à fait valide avec une vraie utilité derrière.

C'est vrai qu'il y'a de quoi se casser les dents (et j'aurais surement paniquer en voyant ce resultat).

Il est dit ici http://docs.oracle.com/javase/specs/...html#jls-5.1.7 qu'apparement on est garantit pour les valeur de -128 a 127 (question de cache si je ne m'abuse). Donc le mieux apparement est de toujours utiliser equals (mais je trouve ca vraiment foireux).

salut,
c´est a cause du cache.
ref: lien ou en francais: http://www.java-freelance.fr/java/revues-de-code-i

Eric

:zekill: wrappers

Je préférais sincèrement quand il n'y a pas d'autoboxing !

Citation:

---

Envoyé par MarieKisSlaJoue

Non, tu peux très bien utiliser le == sur autres chose que des primitifs. Il n'aura juste pas la même signification que sur les type primitif... Je ne vois pas ce que tu veux que Netbeans te prévienne. Ca reste du code tous à fait valide avec une vrai utilité derrière.

---

Personnellement, je ne trouve pas que pouvoir faire == sur des types wrapper serve à quoi que ce soit, à part pour écrire du code de test où on pourrait envisager une annotation qui prévient du fait qu'on va le faire volontairement.

Findbugs permet de prévenir quand on fait ça. Ce serait utile qu'un IDE le fasse directement à la compil.

Je dois mal m'y prendre (comprenez coder) alors !

J'ai commencé il y a pas mal d'années maintenant par du C, variables hyper typées (comme vous le savez bien entendu), et mes IDE de l'époque n'avaient pas la souplesse de ceux d'aujourd'hui en ce qui concerne le debug...
Grosse pause puis je découvre java, et peu après la POO, ainsi que des IDE qui aurait fait ma joie quelques années auparavant.
J'ai pris pour habitude de n'utiliser que des variables "Objets" que vous appelez wrappers, pour leur "simplicité", pour homogénéiser mes codes, et pour ne pas me faire... enfin vous avez saisi ;-)

Après cette douche froide (Cf l'extrait de code en début de post), j'essaye de me remettre en question, en vous en posant justement :
- Est-ce une bonne chose de n'utiliser que des wrappers ? (avec toutes les mécaniques de développement qu'il me faudra garder à l'esprit, comme Integer(2).intValue() =? Integer(2).intValue(), au lieu de 2=?2...)
- Vous limitez-vous à l'utilisation très anecdotique de ces wrappers ?

Je vous pose ces questions car je viens à me demander si je ne dois pas changer mon fusil d'épaule en ce qui concerne ces variables : le gain en "simplicité" me parait maintenant dérisoire si cela nécessite du code, pas forcement compliqué, en plus pour tester 2=?2, cela alourdi considérablement le code.

Quelle est la règle de l'art selon vous ?

@MarieKisSlaJoue : ok en ce qui concerne == entre objet, ce qui me dérange le plus, c'est le comportement différent en fonction d'une limite de chiffre... il n'y a pas d'unicité de fonctionnement. En ce qui me concerne, je trouve ca absolument dangereux de laisser paraitre que 2=2, mais que 129!=129, du coup je pense que, comme Satch, c'est une hérésie l'autoboxing (merci d'ailleurs, je ne connaissais pas le terme)
@thelvin : pour tester si deux objects sont en fait les mêmes, ca peut servir en effet, mais je pense (comme toi, à moins de ne pas avoir compris ton propos) que cela reste rare, je ne vois que l'override de compareTo() en fait...
@Autres : Merci pour les liens, je dormirais avec moins de dents, certes, mais un peu moins bête ;-)

Salut,


Le problème ne vient pas directement de l'autoboxing, mais de la syntaxe du langage.

L'opérateur == a deux significations différentes selon qu'on l'utilise sur des types primitifs ou des objets.

• Il permet de vérifier l'égalité des types primitifs.
  Si a et b sont deux variables de type primitif, alors a==b est vrai si les deux variables ont la même valeur.
• Il permet de vérifier l'identité des objets.
  Si a et b sont des objets, alors a==b est vrai uniquement si les deux variables pointent sur le même objet en mémoire.

L'autoboxing n'est pour rien dans cela, et on peut retrouver la même problématique sans autoboxing :

Code:

---

1 2 3 4 5 6

Integer a = new Integer(0); Integer b = a; Integer c = new Integer(0);   System.out.println( (a==b) + " / " + a.equals(b)); // true / true System.out.println( (a==c) + " / " + a.equals(c)); // false / true

---

Il n'y a rien de faux là dedans.
La notion d'identité est plus stricte que la notion d'égalité, et elle est trop importante pour qu'on l'ignore ! Il n'est pas faut d'utiliser l'opérateur == sur des objets !
Cela n'a juste pas la même signification (égalité sur des types primitifs, et identité sur les objets).

Alors oui il aurait été préférable d'avoir deux opérateurs distincts. Par exemple que == soit mappé sur equals() pour les objets, et qu'on puisse vérifier l'identité via un hypothétique === (qui ne pourrait pas être utilisé sur les primitifs).

Et il est désormais impossible de modifier cela sans casser tous les codes existants !!!

Note : pour la petite histoire l'opérateur == a quand même un sens, puisque l'opérateur d'identité sur des objets consistes ni plus ni moins qu'à vérifier l'égalité des références...



Bref : lorsqu'on travaille avec des objets, on doit utiliser equals() pour vérifier l'égalité.


a++


@Levaillant : je ne vois pas trop l'intérêt d'utiliser les types wrapper à la place des primitifs. Au contraire il est bien plus simple d'utiliser directement les primitifs !

La règle est simple:
- soit tu type en primitif et utilise ==
- soit tu type en objet et utilise equals (aucune exception, si object, equals est vraiment à préférer. Même si ça peut fonctionner quand même avec == c'est une très mauvaise idée, et tu dépends de mécanismes variables en fonction de la version de Java ie. les cache de bytes sont pas forcément implémenté en JRE 1.4, etc.)

La version object à l'avantage non-négligeable de permettre d'utiliser "null" comme valeur pour exprimer "non initialisé, non applicable ou autre truc du genre". Les primitifs ont comme valeur par défaut 0, qui peut facilement être confondu avec un résultat de calcul réel.

Sinon, pour lever des warnings à tout va, le top c'est: http://www.sonarsource.com (préparez-vous à apprendre un tas de trucs que vous n'imaginiez même pas)

Bonjour,
Pill_s a mis le doigt sur la raison qui m'avait incité à utiliser exclusivement des wrappers, le "null".
Travaillant beaucoup sur diverses bases de données, il m'avait semblé opportun de les utiliser.
Vos deux avis semblent confirmer ma première pensée donc, à savoir l'utilisation des wrappers n'est à privilégier que dans des cas où une variable peut-être null, et puis c'est tout !
Merci à tous

Enfin depuis Java 1.8 j'aime pas trop compter sur "null" moi. Je préfère un bon OptionalInt... Bon, c'est un objet aussi, bien sûr.

Ok je connaissais pas, mais en même temps, j'ai pas encore accès à Java 8 pour le dév...

Sinon, ça étend pas Number? Ni Comparable? Ni rien du tout? Pourquoi ils ont fait cette classe du coup? Un OptionalObject générique aurait sûrement fais le même boulot...

EDIT: ha zut ça existe en fait... https://docs.oracle.com/javase/8/doc.../Optional.html... bon bin aucune idée du pourquoi de l'optionalint

Citation:

---

Envoyé par Pill_S

EDIT: ha zut ça existe en fait... https://docs.oracle.com/javase/8/doc.../Optional.html... bon bin aucune idée du pourquoi de l'optionalint

---

Toujours la même chose : les primitifs sont si atypique qu'il faut adapter le code si on ne veut pas passer par les types wrapper et l'autoboxing.
On a donc grosso-modo :

• Optional<T> pour les objets.
• OptionalInt, OptionalDouble et OptionalLong pour les types primitifs correspondant.

Malheureusement l'API de Java est assez pollué par cela...


a++

Citation:

---

Envoyé par Pill_S

bon bin aucune idée du pourquoi de l'optionalint

---

Je partais du principe que ça évite d'avoir deux objets quand un seul suffit pour un besoin simple, et que get().intValue() est moins pratique que getAsInt() pour comparer avec autre int.