Quelqu'un saurait-il ce qui se passe r=E9ellement dans le code suivant,
SVP ? J'ai fait un test compil=E9, bien s=FBr, mais je cherche =E0 d=E9couv=
rir
les d=E9tails de ce probl=E8me.
Long toto =3D 1l;
Long titi =3D 1l;
if (toto =3D=3D titi) {
System.out.println("comparaison des valeurs");
} else {
System.out.println("comparaison des r=E9f=E9rences");
}
En effet, ce sont les valeurs qui sont compar=E9es... on ne peut donc
plus tester les r=E9f=E9rences... Je pensais que l'autoboxing =E9tait
d=E9clench=E9 lorsque les deux natures (objet et type simple) sont
confront=E9es dans une expression.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ToOmS
En mode debug, je m'apperçois que les deux variables ont le même ID. Java crée donc un catalogue (ce sont des objet immuables, alors pourquoi pas). Il est donc normal que la comparaison (même sur les références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une expression dans la comparaison) :
Long toto = 10l; Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) { System.out.println("comparaison des valeurs"); } else { System.out.println("comparaison des références"); }
et le résultat est le même (comparaison des valeurs)...
En mode debug, je m'apperçois que les deux variables ont le même ID.
Java crée donc un catalogue (ce sont des objet immuables, alors
pourquoi pas). Il est donc normal que la comparaison (même sur les
références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une
expression dans la comparaison) :
Long toto = 10l;
Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) {
System.out.println("comparaison des valeurs");
} else {
System.out.println("comparaison des références");
}
et le résultat est le même (comparaison des valeurs)...
En mode debug, je m'apperçois que les deux variables ont le même ID. Java crée donc un catalogue (ce sont des objet immuables, alors pourquoi pas). Il est donc normal que la comparaison (même sur les références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une expression dans la comparaison) :
Long toto = 10l; Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) { System.out.println("comparaison des valeurs"); } else { System.out.println("comparaison des références"); }
et le résultat est le même (comparaison des valeurs)...
Mayeul
ToOmS a écrit :
En mode debug, je m'apperçois que les deux variables ont le même ID. Java crée donc un catalogue (ce sont des objet immuables, alors pourquoi pas). Il est donc normal que la comparaison (même sur les références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une expression dans la comparaison) :
Long toto = 10l; Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) { System.out.println("comparaison des valeurs"); } else { System.out.println("comparaison des références"); }
et le résultat est le même (comparaison des valeurs)...
Je ne peux pas tester là maintenant, mais logiquement Long.valueOf() devrait aussi utiliser le catalogue, et donc renvoyer une référence vers le Long de valeur 10 qui existe déjà.
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), ça donnera false.
-- Mayeul
ToOmS a écrit :
En mode debug, je m'apperçois que les deux variables ont le même ID.
Java crée donc un catalogue (ce sont des objet immuables, alors
pourquoi pas). Il est donc normal que la comparaison (même sur les
références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une
expression dans la comparaison) :
Long toto = 10l;
Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) {
System.out.println("comparaison des valeurs");
} else {
System.out.println("comparaison des références");
}
et le résultat est le même (comparaison des valeurs)...
Je ne peux pas tester là maintenant, mais logiquement Long.valueOf()
devrait aussi utiliser le catalogue, et donc renvoyer une référence vers
le Long de valeur 10 qui existe déjà.
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), ça
donnera false.
En mode debug, je m'apperçois que les deux variables ont le même ID. Java crée donc un catalogue (ce sont des objet immuables, alors pourquoi pas). Il est donc normal que la comparaison (même sur les références) colle.
Mais avec l'exemple suivant, on a bien deux ID (et de toute façon une expression dans la comparaison) :
Long toto = 10l; Long titi = 1l;
if (toto == Long.valueOf(titi + 9l)) { System.out.println("comparaison des valeurs"); } else { System.out.println("comparaison des références"); }
et le résultat est le même (comparaison des valeurs)...
Je ne peux pas tester là maintenant, mais logiquement Long.valueOf() devrait aussi utiliser le catalogue, et donc renvoyer une référence vers le Long de valeur 10 qui existe déjà.
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), ça donnera false.
-- Mayeul
ToOmS
On 1 oct, 19:32, Mayeul wrote:
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), a donnera false.
C'est exact, en effet. Et cela semble assez logique dans la mesure où "new Long(titi + 9l)" dans une expression ne nécessite pas, par définition, d'être catalogué (pas de référence à mettre dans le stack ?).
Je remarque également que le code suivant :
Long toto = 10l; Long titi = 1l; titi += 9l;
Aboutit à l'égalité des ID entre toto et titi. Mais il est probable que #valueOf est utilisé pour l'autoboxing.
On 1 oct, 19:32, Mayeul <mayeul.marg...@free.fr> wrote:
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), a
donnera false.
C'est exact, en effet. Et cela semble assez logique dans la mesure où
"new Long(titi + 9l)" dans une expression ne nécessite pas, par
définition, d'être catalogué (pas de référence à mettre dans le
stack ?).
Je remarque également que le code suivant :
Long toto = 10l;
Long titi = 1l;
titi += 9l;
Aboutit à l'égalité des ID entre toto et titi. Mais il est probable
que #valueOf est utilisé pour l'autoboxing.
Si tu remplaces Long.valueOf(titi + 9l) par new Long(titi + 9l), a donnera false.
C'est exact, en effet. Et cela semble assez logique dans la mesure où "new Long(titi + 9l)" dans une expression ne nécessite pas, par définition, d'être catalogué (pas de référence à mettre dans le stack ?).
Je remarque également que le code suivant :
Long toto = 10l; Long titi = 1l; titi += 9l;
Aboutit à l'égalité des ID entre toto et titi. Mais il est probable que #valueOf est utilisé pour l'autoboxing.
ToOmS
Pour info, les codes suivants aboutissent à des références séparé es :
Long toto = new Long(10l); Long titi = new Long(1l + 9l);
Long toto = new Long(10l); Long titi = new Long(10l);
Pour info, les codes suivants aboutissent à des références séparé es :
Long toto = new Long(10l);
Long titi = new Long(1l + 9l);
Long toto = new Long(10l);
Long titi = new Long(10l);
Pour info, les codes suivants aboutissent à des références séparé es :
Long toto = new Long(10l); Long titi = new Long(1l + 9l);
Long toto = new Long(10l); Long titi = new Long(10l);
Mayeul
ToOmS a écrit :
Pour info, les codes suivants aboutissent à des références séparées :
Long toto = new Long(10l); Long titi = new Long(1l + 9l);
Long toto = new Long(10l); Long titi = new Long(10l);
C'est normal, c'est ce que veut dire new : construction d'un nouvel objet, donc d'une référence vers ce nouvel objet.
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un système de catalogue existe. Allouer et conserver de nouveaux objets triviaux coûte cher quand on en abuse.
-- Mayeul
ToOmS a écrit :
Pour info, les codes suivants aboutissent à des références séparées :
Long toto = new Long(10l);
Long titi = new Long(1l + 9l);
Long toto = new Long(10l);
Long titi = new Long(10l);
C'est normal, c'est ce que veut dire new : construction d'un nouvel
objet, donc d'une référence vers ce nouvel objet.
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un
système de catalogue existe. Allouer et conserver de nouveaux objets
triviaux coûte cher quand on en abuse.
Pour info, les codes suivants aboutissent à des références séparées :
Long toto = new Long(10l); Long titi = new Long(1l + 9l);
Long toto = new Long(10l); Long titi = new Long(10l);
C'est normal, c'est ce que veut dire new : construction d'un nouvel objet, donc d'une référence vers ce nouvel objet.
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un système de catalogue existe. Allouer et conserver de nouveaux objets triviaux coûte cher quand on en abuse.
-- Mayeul
ToOmS
On 2 oct, 10:45, Mayeul wrote:
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un système de catalogue existe. Allouer et conserver de nouveaux objets triviaux coûte cher quand on en abuse.
Tout à fait. Et si j'avais mieux compris(lu ?) l'API Long#valueOf(long) au lieu de me fier aux vieilles habitudes, j'aurais tout de suite compris la différence... J'ai définitivement besoin de vacances !
Cela dit, on atteind bien, comme je le pressentais, certaines limites de l'autoboxing ; on crée la confusion en laissant croire que la comparaison de deux objets est celle de leurs valeurs. Quelques cafouilles entre new et valueOF... et on l'a dans l'os !
Bonne fin de journée.
On 2 oct, 10:45, Mayeul <mayeul.marg...@free.fr> wrote:
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un
système de catalogue existe. Allouer et conserver de nouveaux objets
triviaux coûte cher quand on en abuse.
Tout à fait. Et si j'avais mieux compris(lu ?) l'API
Long#valueOf(long) au lieu de me fier aux vieilles habitudes, j'aurais
tout de suite compris la différence... J'ai définitivement besoin de
vacances !
Cela dit, on atteind bien, comme je le pressentais, certaines limites
de l'autoboxing ; on crée la confusion en laissant croire que la
comparaison de deux objets est celle de leurs valeurs. Quelques
cafouilles entre new et valueOF... et on l'a dans l'os !
Il me semble logique de ne pas faire de "new" pour l'auto-inbox si un système de catalogue existe. Allouer et conserver de nouveaux objets triviaux coûte cher quand on en abuse.
Tout à fait. Et si j'avais mieux compris(lu ?) l'API Long#valueOf(long) au lieu de me fier aux vieilles habitudes, j'aurais tout de suite compris la différence... J'ai définitivement besoin de vacances !
Cela dit, on atteind bien, comme je le pressentais, certaines limites de l'autoboxing ; on crée la confusion en laissant croire que la comparaison de deux objets est celle de leurs valeurs. Quelques cafouilles entre new et valueOF... et on l'a dans l'os !
