Discussion :

[chimomura]

Bonjour à tous,

j'aurais une question qui m'embrouille sur un exemple que j'ai trouvé sur un livre sur la programmation concurrente en java dans le quel on donne un exemple d'une classe qui est modifiable alors que moi je pense qu'elle ne l'est pas.

la classe en question est la suivante

Code :

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

1
2
3
4
5
6
7
8
public class Holder { 
  private int n; 
  public Holder(int n) { this.n = n; } 
  public void assertSanity() { 
    if (n != n) 
      throw new AssertionError("This statement is false."); 
  } 
}

et qui sera appelée par des threads dans un bout de programme comme le suivant :

Code :

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

1
2
3
4
public Holder holder; 
public void initialize() { 
  holder = new Holder(42); 
}

Donc, qd je regarde l'exemple je suis un peu confus, car une classe immutable est une classe dans la quelle chaque référence d'objet de cette classe ne peux pas changer la valeurs de ces champs une fois construits.

Pour moi, la classe Holder est immutable par costruction, même si le int n de l'objet holder n'est pas final !!!

Est ce que quelqu'un aurait une explication et pourrais me dire dans quelle cas un objet holder pourrait changer de valeur (d'état) sans changer de référence ?

Merci d'avance pour votre aide.

[thelvin]

Pour moi, la classe Holder est immutable par costruction, même si le int n de l'objet holder n'est pas final !!!

Est ce que quelqu'un aurait une explication et pourrais me dire dans quelle cas un objet holder pourrait changer de valeur (d'état) sans changer de référence ?

Moi non plus ça ne me semble pas possible en conditions normales.
Ça doit pouvoir arriver avec du JNI, mais bon... Quand on en arrive là, on a d'autres soucis qu'assurer les accès concurrents .

Je suppose qu'on est censé rendre la classe Holder mutable, à l'aide d'un setter.

[chimomura]

Bonjour thelvin,

C'est ce que je pense moi aussi.

Donc, je peux très bien avoir une classe immutable avec des champs (contentons nous des champs primitifs) qui soient non final mais juste private qui sont initialisés dans le constructeur et sans aucun setter sur ces champs ?

Merci.

[thelvin]

Donc, je peux très bien avoir une classe immutable avec des champs (contentons nous des champs primitifs) qui soient non final mais juste private qui sont initialisés dans le constructeur et sans aucun setter sur ces champs ?

Disons que je ne trouve pas ça très propre. Quand on fait une classe immutable, on déclare ses champs final, point.

Mais sauf erreur de ma part, oui, on peut faire des classes immutables sans les champs soient vraiment final.

[adiGuba]

Salut,


A noter que pour être réellement immuable, il faut également que la classe elle-même soit déclarée final afin de ne pas pouvoir être redéfinie. Sinon l'immuabilité ne peut pas être redéfinie.


Concernant les champs ce n'est pas forcément une obligation, mais c'est nettement plus simple car cela rend le tout obligatoirement thread-safe...


@chimomura : concernant l'exemple je pense qu'ils veulent montrer que la condition (n != n) peut être vrai dans certains cas lorsque l'attribut n'est pas final... Mais il faudrait voir l'exemple complet.

a++

[chimomura]

Pour vous donner le contexte complet de l'exemple,

en fait,

on dispose d'une classe

Code :

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

1
2
3
4
5
6
7
8
public class Holder { 
  private int n; 
  public Holder(int n) { this.n = n; } 
  public void assertSanity() { 
    if (n != n) 
      throw new AssertionError("This statement is false."); 
  } 
}

cette classe est utilisé dans le bout de programme suivante, où elle est accédé par plusieurs thread

Code :

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

1
2
3
4
public Holder holder; 
public void initialize() { 
  holder = new Holder(42); 
}

dans le livre est dit :
" Vous pourriez être surpris des conséquences de cet exemple qui semble pourtant anodin.
À cause des problèmes de visibilité, l’objet Holder pourrait apparaître à un autre thread sous un état incohérent, bien que ses invariants aient été correctement établis par son constructeur ! Cette publication incorrecte pourrait permettre à un autre thread d’observer
un objet partiellement construit "

Moi, je suis d'accord sur le fait que d'autre threads pourraient voir l'objet holder en état partiellement construit alors qu'il est entrain d'être construit par un autre thread en même temps. toutefois, le problème ici est non pas la classe Holder elle-même, mais le fait que l’objet Holder ne soit pas
correctement publié.

autrement dit, si je mets

Code :

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

public static Holder holder = new Holder(42);

ou lieu de

Code :

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

1
2
3
4
5
 
public Holder holder; 
public void initialize() { 
  holder = new Holder(42); 
}

je garantis que les threads ne verront plus d'objet partiellement construit.
sans pour autant modifier la classe Holder

Cependant, on pourrait immuniser Holder contre une publication incorrecte en
déclarant le champ n final, ce qui rendrait Holder non modifiable

jusqu'au là j'ai compris.

Par contre, c'est dit après toujours dans le livre pour cet exemple :

" Cependant, on pourrait immuniser Holder contre une publication incorrecte en déclarant le champ n final, ce qui rendrait Holder non modifiable"

et

" Les objets non modifiables ayant tant d’importance, le modèle mémoire de Java garantit une initialisation sûre pour les partager "

et

" Pour que cette garantie d’initialisation sûre puisse s’appliquer, il faut que toutes les exigences portant sur les objets non modifiables soient vérifiées : 1) état non modifiable ,
2) tous les champs déclarés comme final
3) construction correcte "

Et là ou je comprends pas pourquoi l'objet holder tel qu'il est déclaré pourquoi il est mutable ?

Merci pour votre aide.