Discussion :

[Christophe Genolini]

Bonjour,

Si j'ai bien compris, int est un type de base, Integer est une classe. int est stocké sur la pile ; Integer dans la RAM. De plus, Integer dispose de méthodes de manipulation. Ensuite, j'ai plus de mal...

• Pile versus RAM : Cela signifie-t-il que la manipulation des int est plus rapide que les Integer ? Je suppose que le nombre d'int créable est plus limité que celui des Integer ? Avez-vous des ordres de grandeur du nombre d'int et d'Integer que peuvent contenir les deux mémoires ?
• J'ai lu, via google, que int était plus facile à manipuler : avec mes maigres connaissances, j'ai essayé des + et des ++, les fonctionnements des deux sont identiques. Idem pour System.out.println. Je suppose que avant(une ancienne version de Java ?), Integer était plus difficile à manipuler mais que maintenant c'est réglé ?

Christophe

[maxusn]

Bonjour,

pour ce qui est de l'allocation mémoire : un int prends 4 octets en mémoire mais un Integer utilisera 32 octets sur une machine virtuelle en 64 bits (20 octets en 32 bits).

La classe Integer est une classe wrapper (une sorte de conteneur : un Interger est une référence sur un nombre ou sur "null")

voila qui pourrait peut être t’éclairer un peu :

Les enveloppeurs (Wrappers)

Chacun des types primitifs peut être "enveloppé" dans un objet provenant d'une classe prévue à cet effet et appelée Wrapper (mot anglais signifiant enveloppeur). Les enveloppeurs sont donc des objets représentant un type primitif.

Avantages :

Les Wrapper peuvent être utilisés comme n'importe quel objet, ils ont donc leurs propres méthodes.

Inconvénients :

L'objet enveloppant utilise plus d'espace mémoire que le type primitif. Par exemple, un int prends 4 octets en mémoire mais un Integer utilisera 32 octets sur une machine virtuelle en 64 bits (20 octets en 32 bits).


L'objet enveloppant est immuable, c'est à dire qu'il ne peut pas être modifié, toute modification de sa valeur nécessite de créer un nouvel objet et de détruire l'ancien, ce qui augmente le temps de calcul.

[thelvin]

Pile versus RAM

Alors déjà la pile fait partie de la RAM. C'est pas un espace magique. Ce qu'on oppose d'habitude à la pile, c'est le tas (en anglais, heap.)

Par ailleurs ce sont les variables locales, qu'on stocke dans la pile. Tu as raison quand tu dis qu'une variable de type de base, est mise dans la pile, et y est mise entièrement. Alors qu'une variable de type objet, c'est juste le pointeur vers cet objet, qui est mis dans la pile. L'objet lui-même est mis dans le tas. Contrairement aux types de base qui sont simples et atomiques, les types objets sont "pointés vers."

Mais bien entendu, un objet peut contenir des variables d'instances. Si on lui met un int dedans, il contient un int, si on lui met des objets, il contient des pointeurs vers ces objets. Et tout ce petit monde faisant partie de l'objet, ce sera stocké avec l'objet, dans le tas.

Mais toutes ces histoires de pile et de tas sont théoriques, c'est juste le modèle de conception, "le programme aura le même résultat que si tout se passe comme ça." Mais Java se permet des optimisations quand ça l'arrange. Dans toute sa petite cuisine cachée, lorsqu'il détecte qu'un objet a un cycle de vie court, qui convient bien à la pile, il peut très bien le mettre dans la pile véritable, au lieu d'ailleurs.

Conclusion : ça n'a pas de sens de dire qu'un int est dans la pile et un Integer dans le tas. On dira plutôt qu'un int est directement accessible et qu'un Integer est déréférencé, d'un pointeur vers l'objet lui-même.

Cela signifie-t-il que la manipulation des int est plus rapide que les Integer ?

Oui. Le contenu utile du int, c'est lui-même, accessible directement. Alors qu'un Integer ne sert qu'à contenir un int en lui, et cet int n'est accessible qu'à travers un appel de méthode à Integer. Un appel de méthode est assez coûteux, par rapport à... Ben par rapport à ne rien faire.
De plus, créer un Integer c'est créer un objet, et il faudra aussi le désallouer, tout ça est coûteux en temps et en mémoire. Comparé à juste une variable 32-bits toute simple.

Je suppose que le nombre d'int créable est plus limité que celui des Integer ?

What ? Non. Il n'y a pas vraiment de logique de ce genre, mais de manière générale, avoir des Integer est plus coûteux qu'avoir juste des int.

En résumé, quand on doit choisir entre int ou Integer, c'est simple. Si on peut => int. Sinon => Integer.

J'ai lu, via google, que int était plus facile à manipuler : avec mes maigres connaissances, j'ai essayé des + et des ++, les fonctionnements des deux sont identiques. Idem pour System.out.println. Je suppose que avant(une ancienne version de Java ?), Integer était plus difficile à manipuler mais que maintenant c'est réglé ?

Ce qu'on appelle l'autoboxing, depuis Java 1.5, a pas mal simplifié les choses... En théorie.
En gros, il y a conversion implicite de Integer vers int et de int vers Integer, quand il est clair que c'est la conversion implicite voulue.
Ce n'était pas le cas avant Java 1.5, et du coup, les opérateurs + ou ++ ou rien d'autre que . ne marchaient sur les Integer.

Aujourd'hui il est possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Integer i = 5;
i++;

Dans le temps il aurait fallu faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Integer i = 5;
i = new Integer(i.intValue()+1);

Et en réalité il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int i = 5;
i++;
// et si on a besoin d'un Integer, on verra ça plus tard

Malheureusement, l'autoboxing peut amener à croire qu'on travaille avec un int alors que c'était un Integer, ou l'inverse. Ce qui peut amener à se tromper par exemple d'appel de méthode, qui peut accepter int ou Object en paramètre. En cherchant à simplifier les choses, l'autoboxing a donc introduit de nouvelles difficultés plus subtiles.

[Christophe Genolini]

Merci pour cette réponse détaillée, ce topic est résolument Résolu

Je me permets néanmoins de poser une deuxième question, qui n'est plus du tout une question de débutant, mais qui est la suite directe de la précédente.

D'après ce que je comprends, java demande à l'utilisateur de spécifier s'il veut un int ou un Integer. Serait-il envisageable, dans un autre monde avec un autre Java, de ne pas demander à l'utilisateur de choisir, et que java choisisse lui-même à la compilation ? Par exemple, je considère le programme suivant (je me place à l'époque ou l'auto-boxing n'existait pas) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public class essai {
	public static void main(String[] args) {
		int a=3;
		Integer b=new Integer(5);
		a++;
		b.intValue()++;
		System.out.println(a);
		System.out.println(b);
	}
}

On pourrait imaginer l’existence d'un type "integ" qui serait soit un int, soit un Integer, mais cela ne serait pas à l'utilisateur de le spécifier. Par exemple, l'utilisateur taperait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public class essai {
	public static void main(String[] args) {
		integ a=3;
                integ b=5; 
		a++;
		b.intValue()++;
		System.out.println(a);
		System.out.println(b);
	}
}

Ensuite, cela serait à "l'autre java d'un autre monde" de choisir le type précis de a et de b, lors d'une pré-compilation.

• Aux lignes 3 et 4, java ne peut pas connaitre les types exact de a et b. Il suppose que c'est des int.
• A la ligne 5, il a confirmation que que a est un int.
• A la ligne 6, il réalise que le type int ne sera pas suffisant pour b. b a besoin d'être un Integer. b sera donc un Integer, et cela dès la ligne 4.

Il peut donc traduire le code avec integ en un code java avec des int et des Integer.

...

Pour ceux qui se demande ou je veux en venir : Non, je n'ai pas l'intention de ré-écrire Java...

Je suis juste en train d'écrire un petit langage à destination de non informaticiens. Ce langage doit être efficace, mais simple. Je me pose donc la question de l'intégration dans mon langage de "types indifférenciés" (donc simples pour l'utilisateur) puis choisis par le langage lui-même en fonction des besoin (donc efficace).

Christophe

[thelvin]

Ce dont tu parles est un peu comme dans Python, où tout est objet et où il n'y a pas de type de base. Pourtant, manipuler des nombres simples comme nos int Java ne consomme pas plus de ressource que si c'était des types de base.
Parce qu'en réalité c'est le langage qui s'occupe de le traiter comme une pauvre variable 32-bits tant que c'est possible, et qui applique le modèle objet seulement quand demandé.

Il paraît que c'est vaguement discuté pour Java 10 : fin des types de base, ils deviennent tous objet, et c'est Java qui s'occupe de faire ce qui est le mieux.
Conceptuellement c'est pas plus compliqué que ça, mais pour la compatibilité ascendante ça va être un gros bordel.

[tchize_]

Pas vraiment, suffirait de déléguer tout le boulot à la JIT. Du coup tu partirais du principe:

si c'est déclaré int, c'est pas un objet
si c'est déclaré Integer, ce ne sera qu'un objet si c'est vraiment nécessaire

Après tout, ce ne serait pas la première bidouille que ferait le JIT pour analyser et optimiser le bytecode.

[Christophe Genolini]

On peut même aller un cran plus loin : avec le système que propose tchize_, int ne sert plus vraiment a quelque chose, puisque quand une variable peut être int, alors JIT le détecte. On peut donc tout déclarer integer, JIT fera le tri.

Christophe