Légende urbaine : En java, les objets sont passés par référence

Handle est un terme bien peu transparent. On l’utilise pour tellement de choses ! Je préfère dire que les objets sont passés par pointeur car en Java, tout est pointeur même si ça dit pas son nom :-)

Ta méthode nullify ne prouve rien.
Lorsque tu passes un objet par référence, ceci signifie que tu passes en fait une référence vers un objet ; autrement dit, un pointeur constant vers la zone mémoire où réside ton objet. Par conséquent que tu ne peux pas réassigner une valeur à ta référence. Donc, si effectivement le paramètre passé en argument de nullify était une vraie référence, alors le compilo aurait refusé de compiler ton code pour assignement de valeur à une … constante (sachant que, contrairement à C++, Java n’autorise pas la surcharge des opérateurs (donc de =))

Donc, ce ce n’est pas l’appel assertNotNull(value) qui est la preuve … mais plutôt le résultat de la compilation qui n’aboutit pas à une erreur.

@Steve

Un pointeur mémoire n’implique pas forcément mémoire physique.

@waddle
« Lorsque l’on parle d’un passage par référence, il faut bien comprendre que c’est la variable qui serait passée par référence et non pas l’objet qu’elle désigne. »
Oui, dans Java. D’où le sujet de ton article au sujet des références vs. handlers. Je n’ai pas dis le contraire. J’ai juste indiqué que ton exemple n’était pas suffisant pour monter ceci.

Sinon, en réponse à ton post 6, au sujet des références constantes et C++ :
En C++, une référence sur un objet toto n’est en fait qu’un :
toto * const
C’est à dire un pointeur constant et qui donc doit être initialisé. (A l’époque où je faisais encore du C++, cette notation et celle de la référence (avec le &) était marquée comme équivalente).
Ce qui fait que tu peux écrire :
const toto & => const toto * const
Autrement dit une référence sur un objet constant ! (Ce n’est pas la référence qui est constante, puisque par sa nature même, elle est par définition constante !)
Maintenant, tu peux avoir une erreur en C++ avec les références lorsque tu les réassigne non pas pour cause de réassignement de référence … mais parce que ton objet référencé ne fournit pas d’implémentation à l’opérateur ‘=’ ! Donc, si ton objet implémente l’opérateur ‘=’ alors ce que tu crois être une réassignation n’est en fait qu’une copie d’un objet existant vers un autre.

J’ai bossé sur une façade Java utilisée en JNI dans un autre programme .Net.
Ces problèmes de vocabulaire sont primordiaux dans les contrats d’interfaces pour éviter des confusions et communiquer correctement entre les projets.
Donc, oui je pense que ces discussions ont un vrai intérêt.

Pour s’en convaincre, il suffit de compiler la classe et d’utiliser javap pour voir le bytecode généré. C’est d’autant plus simple à comprendre puisque javap affiche ligne par ligne le code exécuté.

Le bytecode Java permet de voir les opérandes mises sur la pile.

« En java, les paramètres pour les types primitifs sont passés par valeur, et pour les types objets c’est une copie de la référence Java (un Handle) qui est transmise. »

Un article petit par la taille et grand par sa richesse.

hello,

je suis pas totalement d’accord avec votre conclusion. Suite a votre article nous avons fait un test avec un collégue a ce sujet.
En effet lorsque dans le nullify on met a null l’objet il est a null le temps de vie de la méthode et c’est sur un objet intermédiaire puisque qu’on a pas le droit de mettre une référence à null.

Le bout de code ci dessous essaye de montrer qu’en fait malgré le fait qu’on passe à null et que un objet intermédiaire soit crée on passe quand meme notre objet par référence :
public class memory {
public static void main(String[] args)
{
StringBuilder t = new StringBuilder(« toto »);
test(t);
System.out.println(t.toString());
}

public static void test(StringBuilder t) {
t.append(« hahaha »);
t = null;
if (t == null) {
System.out.println(« t est null »);
}
}
}

voici ce qu’on obtient sur la console :
t est null

totohahaha

Du coup le t.append fonctionne bien et si nous passions notre objet par copie sur le syso suivant on aurait pas le « totohahaha »

Peut être ai-je faux quelque part. Je tiens a préciser que je suis juste pas totalement en accord avec la conclusion sur le cas là. :)

cordialement,

Cet article est totalement faux tout comme le dernier commentaire.

Une référence par définition est constante dans le sens ou on ne peut pas séparer le référé de sa référence. Ce qui n’a rien avoir avec le mot const du c++ (comme ecrit dans un commentaire + haut) qui indique que l’objet référencé ne sera pas modifié.

int i=9;
test(i);

void test(const int& reference) { affiche i }
//la on dit au compilateur que l’objet référencer par reference ne sera pas modifié.

En java on ne fait QUE des passages par référence sur les Objets.
Le code de Nicolas G est tout a fait juste et prouve les mauvaises conclusions de l’article. Le message de RobPred5 va également dans ce sens.

Dans la methode test de NicolasG on passe l’objet par référence. Le .append ne déréférence absolument pas l’objet mais modifie l’objet référé (t du main).
le t = null; déréférence l’objet t (celui de la methode test) mais qui n’est visible que dans la methode test. Donc une fois que la méthode est terminée l’objet t de la methode test qui est une référence disparait également.
Donc il ne reste plus que l’objet t du main.

On déréférence avec un = et si je fais dans la method test:
StringBuilder u = new SB(« tata »);
t = u;

La durée de vie de l’objet u n’est que la methode elle meme donc quand je reviens dans le main t ne peut etre egale a u car u va etre GBC(garbage collecté) car il est sorti des {} de la méthode (ca durée de vie).

Il est possible de dire que l’on peut déréférencer un objet mais il est pas possible de dire qu’on fait un passage par copie.

@Stan

Je pense que c’est vous qui vous trompez car vous utilisez mal le mot « référence ». Ce mot a un sens depuis que le C++ est C++. Parlé de référence pour l’argument d’une méthode Java est totalement abusif.

void foo()
{
int i=9;
test(i);
}

void test(int& reference) { i=0}

A la sortie de test(), le i de foo() vaut 0. C’est cela une référence. En Java, ce n’est pas le cas donc parlé de référence est abusif.

Comme dirait Akim Demaille : « En Java, tout est pointeur ».
Et comme dirait Scott Stanchfield : « Java is strictly pass-by-value, exactly as in C » (http://javadude.com/articles/passbyvalue.htm)

@Stan

Tiré de votre lien : « Reference data type parameters, such as objects, are also passed into methods *by value* ». Oracle fait donc bien une erreur en parlant de référence puisqu’ils ne font pas autorité en OOP à ce que je sache. Ou alors c’est celui qui a créé NullPointerException qui a fait une erreur ?

Quant à ce qu’Oracle soit la référence en Java, je ne suis pas d’accord. La référence, c’est James gosling et il dit dans « The Java Programming Language » :

« Some people will say incorrectly that objects in Java are « pass by reference. » The term pass by reference *properly means* that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory. […] There is exactly one parameter passing mode in Java (pass by value) and that helps keep things simple. »

Pour votre gouverne, je ne suis pas puéril en voulant jouer sur les mots. Les mots ont un sens et c’est parce qu’on ne le respect pas qu’on en est à avoir ce genre de discussion.

« (Ou pointeur si cela vous convient mieux) » : bref…

Bonjour,

1 kilo octet ne fais plus 1024 Octets mais 1000 Octets Wouaaah….vite une mise à jour….

Je dirai que pour la phrase : « lors d’un appel de méthode en java, les paramètres de type primitif sont passés par valeur, et ceux de type objet sont passés par référence » c’est un peu la même chose, c’est une histoire d’effort intellectuel.

Pour ma part, je sais qu’en JAVA les paramètres primitif sont passés par valeur et les autres par pointeur. Cet article l’illustre très bien. Le passage par référence n’existe pas en JAVA !

Explications:

Le passage par valeur : Tout le contenu de la variable est recopié sur la pile par l’appelant et sera dépilé par l’appelé. L’appelé manipule donc UNE COPIE de l’objet.

Le passage par pointeur : L’adresse mémoire de l’objet est déposé sur la pile par l’appelant et sera dépilé par l’appelé. L’appelé manipule l’objet ORIGINAL.

Le passage par référence : L’adresse mémoire de la VARIABLE pointant l’objet est déposé sur la pile par appelant. L’appelé manipule donc la VARIABLE ORIGINAL et par voie de conséquence l’OBJET ORIGINAL. Seul ce mode, le passage par référence, permet de modifier le contenu des variables de l’appelant.

En espérant avoir apporté quelques lumières à quelques uns.

Au plaisir de vous lire.

Romuald

Philippe Mougin dit très clairement les choses.

Je sais pas trop pour l’affirmation de Gosling, je viens de faire le test, voilà mon code : (CODE)

MutableInt idx = new MutableInt();
String str = ClasseUtil.getStr(idx);
System.out.println(idx.get()+ » $ « +str);

public class MutableInt {
private int n = 0;
public MutableInt(int i) { this.n = i; }
public MutableInt() {}
public int get() { return this.n; }
public void set(int i) { this.n = i; }
}

public static String getStr(MutableInt ix) {
int nb = new Random().nextInt(9), i = -1;
ix.set(nb);
BufferedReader is = null;
String str = «  »;
// Blablabla retourne str
}

(/CODE) et mon résultat en une ligne:
4 $ Contenu

Hello,
En fait le nullify instancie un nouvel objet.
En ce qui concerne copy.append(« it works as expected »);
Tu as http://stackoverflow.com/questions/8011338/how-is-stringbuffer-implementing-append-function-without-creating-two-objects

« As internal structure there is a char array, not a String. It is initially built with length 16 and will be increased every time the capacity is exceeded. If the Strings to append fit within the char array, there is no need to create new Objects. »

Voili voilou.

Pour que tout soit clair en terme de vocabulaire (^_^)
indices que je vais utiliser:
(a) = quelque soit le langage objet utilisé, car appartient à un domaine de définition au delà du « langage ».
(C/C++) = tire ses origines du C, de ses ancêtres que je ne connait pas, et de tous les
langages qui ont fidèlement suivi sont credo. Donc éviter absolument de l’utiliser pour tous les langages.

J’ai lu l’article et tous les commentaires. En effet le sujet est délicat; pour vous dire la vérité je viens à l’instant de me frotter à cette problématique.
La raison pour laquelle certains ne saisissent pas le principe et que d’autres disent la même chose mais sans se comprendre est que personne ne redéfinit clairement les expressions « pointeur », « adresse », « référence », « pile d’exécution », « espace de nom », l’opérateur « . » .
Des termes qui méritent le détour car malgré l’expérience de plusieurs dans le domaine, il restera toujours des personnes(comme moi surement) pour qui c’est ambiguë. D’après ce que j’ai compris de mes lectures et de mon expérience(hésitez pas à corriger si je dis de la merde). Dans le cadre de l’exécution d’un programme:

– (a) « Une pile d’exécution » est un espace mémoire créé à chaque fois qu’on entre dans une fonction, et un des sous-ensemble de la pile d’exécution est:

– (a) « l’espace de noms » qui correspond à des pointeurs et/ou références qui n’existerons que pendant l’exécution de la fonction.

– (a) « l’adresse » peut désigne grossièrement le numéro de location d’une donnée dans la RAM.

– (C/C++) « le pointeur » est le nom simplifié que nous donnons à une adresse dans l’espace de nom d’une pile d’exécution.

– (C/C++) Lorsque dans un programme, on attribue pour la première fois un nom à une adresse, on appelle ce nom le pointeur. Si pour la même adresse, on attribut un autre nom(dans le même programme), ce nom sera « la référence ».

– (C/C++) Soit « objet » un pointeur, ou une référence. Lorsqu’on fait « objet. », on accède directement(sans copie) au contenu de la case mémoire dont le l’adresse a été simplifié par le nom « objet ».

En partant de ça, j’ai déduit le comportement de la JVM:

– Dans une fonction même pile d’appel même espace de nom:

/*Création d’un objet(ou instance de classe) Toto ayant comme pointeur « toto1 » et stockant « contenu1 » dans la case mémoire liée à toto1.*/
Toto toto1 = new toto(contenu1);

/*Allocation d’une nouvelle case mémoire pour un objet de classe Toto ayant comme pointeur « toto2 », et copie du « contenu1 » de toto1 dans toto2.
Je suppose que c’est l’équivalent du tristement célèbre constructeur par copie du C++. */
Toto toto2 = toto1;

–IMPORTANT–> /*changement de la case sur laquelle pointe toto1 uniquement dans la pile d’appelle actuelle(je met en exergue le « actuelle » svp). Ainsi l’ancien « contenu1 » est perdu à jamais dans la pile actuelle(sauf si on l’a sauvé dans une autre case) et attend d’être balayé par le garbage collector.*/
toto1 = null; //ou
toto1 = new Toto(contenu2);

– Soient les fonctions « void fonction1(int in) », « void fonction2(Toto in1):

Le cas de fonction1(int in) est trivial, car le passage en paramètre d’un type primitif est par valeur. En effet, la pile d’exécution de « fonction1 » possède une adresse nommée en pointeur « in » dont le contenu sera une copie de l’entier passé en paramètre.

Pour fonction2(Toto in1), Toto étant un objet, le paramètre « in1 » se transformera en « référence »(et oui, ici on peut en le dire je pense) pour l’objet de type Toto passé en paramètre. C’est pourquoi, modifier le contenu de in1, équivaudra à modifier le contenu de cet objet. Mais pourquoi lorsqu’on fait
in1 = null; cela ne change pas la valeur de l’objet passé en paramètre hors de la fonction? Et là je vous renvoie à –IMPORTANT– qui explique exactement ce qui se passe dans le contexte d’exécution d’une fonction.

Ainsi, dans l’article, lorqu’on fait copy = null, le pointeur « copy », initialement « référence » de « value »(à l’entrée) de la fonction, devient un pointeur sur la case dont l’adresse est nommée « null ». Cela serait revenu au même si on avait fait copy = new StringBuilder; .