Est-il utile de faire du boxing en Java ?

Bonjour :)
par exemple encapsuler un "R" dans du String ?
ou un int dans du Integer ?
;)

Bonjour,

Oui c'est utile car ça permet d'utiliser des classes/méthodes qui manipulent des objets et pas de types primitifs, par exemple les collections comme java.util.List:

Code:

---

1 2	List<Integer> list = new ArrayList<Integer>(); list.add(Integer.valueOf(10));

---

Ça permet aussi de représenter l'absence de valeur avec null si on ne veut pas utiliser une valeur primitive par défaut, par exemple:

Code:

---

1 2	Integer integer = null; int i = null; // ne compile pas

---

Au passage, il existe la classe Character pour "wrapper" un char

Citation:

---

Envoyé par -gma-

Oui c'est utile car ça permet d'utiliser des classes/méthodes qui manipulent des objets et pas de types primitifs [...]

---

Je prolongerais alors la question : doit-on en arriver à bannir les types primitifs au profit du tout objet ?

Citation:

---

Envoyé par Robin56

Je prolongerais alors la question : doit-on en arriver à bannir les types primitifs au profit du tout objet ?

---

En Java je dirai non car ce n'est pas du "pur objet". Et si c'était le cas il n'y aurait plus de distinction entre les deux je pense.

Mais le int, par exemple, sert pour accéder aux index d'un tableau, donc je ne vois pas l'intérêt de manipuler les Integer à tout bout de code.

Citation:

---

Je prolongerais alors la question : doit-on en arriver à bannir les types primitifs au profit du tout objet ?

---

Il y avait justement un article du dev mag là-dessus:
ftp://ftp-developpez.com/magazine/DevMag201010.pdf
Page 2, colonne de droite en haut

Citation:

---

Il pourrait être intéressant de passer au tout-objet et de se
débarrasser de cela.
Les types primitifs pourraient être remplacés par le type
wrapper correspondant (quitte à ce que la JVM continue à
les utiliser en interne pour des raisons de performance si
besoin)...

---

Citation:

---

Envoyé par provirus

Il y avait justement un article du dev mag là-dessus:
ftp://ftp-developpez.com/magazine/DevMag201010.pdf
Page 2, colonne de droite en haut

---

d'accord tout se discute ... c'est l'option Groovy, mais ce n'est pas si simple.
exemple: tu peux affecter un int à un double mais pas un Integer à un Double... et il y en a d'autres comme ça :cry:....

Une telle évolution nécessiterait bien sûr l'adaptation des casts ; ça serait loin d'être absurde, en tout cas.

Attention qu'un objet consomme plus de mémoire qu'un type de base, on aura toujours besoin des types de base pour les opérations de base. Par exemple, un byte[5000000] consommera 4 à 8 fois de mémoire qu'un Byte[5000000] (8 bits vs un référence supposé occuper 32 ou 64 bits suivant la jvm).

Si l'on veux abolir la frontière, il faudrait presque faire l'inverse, tout travailler en int/byt (du moins en interne) et ne jamais instancier les Object (c'est à dire donner automatiquement au vol la nature objet à la valeur sans allocation particulière) mais là on passer à un sacré remaniement de la JVM :aie:

Citation:

---

Envoyé par Robin56

Je prolongerais alors la question : doit-on en arriver à bannir les types primitifs au profit du tout objet ?

---

Non.
L'article que cite provirus est intéressant mais il se place dans le cas d'un hypothétique nouveau langage Java incompatible avec l'ancien.
Java n'a pas été conçu pour gérer le tout objet et ce n'est plus faisable sans tout casser.

l'auto-(un)boxing de Java n'est qu'une rustine ajoutée à l'origine pour utiliser simplement les types primitifs dans les collections génériques. Mais il est très insuffisant pour permettre de remplacer systématiquement les primitifs par des objets.

Utiliser les objets lorsque ce n'est pas nécessaire :
- plombe les performances inutilement
- alourdit le code si on les utilise correctement (en tant qu'obets)
- conduit à des erreurs bêtes si on les utilise naïvement (comme des primtifs)