La modification finale champs en Java

Nous allons commencer avec un simple cas de test:

import java.lang.reflect.Field;

public class Test {
  private final int primitiveInt = 42;
  private final Integer wrappedInt = 42;
  private final String stringValue = "42";

  public int getPrimitiveInt()   { return this.primitiveInt; }
  public int getWrappedInt()     { return this.wrappedInt; }
  public String getStringValue() { return this.stringValue; }

  public void changeField(String name, Object value) throws IllegalAccessException, NoSuchFieldException {
    Field field = Test.class.getDeclaredField(name);
    field.setAccessible(true);
    field.set(this, value);
    System.out.println("reflection: " + name + " = " + field.get(this));
  }

  public static void main(String[] args) throws IllegalAccessException, NoSuchFieldException {
    Test test = new Test();

    test.changeField("primitiveInt", 84);
    System.out.println("direct: primitiveInt = " + test.getPrimitiveInt());

    test.changeField("wrappedInt", 84);
    System.out.println("direct: wrappedInt = " + test.getWrappedInt());

    test.changeField("stringValue", "84");
    System.out.println("direct: stringValue = " + test.getStringValue());
  }
}

Quiconque le soin de deviner ce qui va être imprimé en sortie (indiqué en bas pour ne pas gâcher la surprise immédiatement).

Les questions sont:

Pourquoi primitive et enveloppé entier se comporter différemment?
Pourquoi ne réfléchissant vs un accès direct retour des résultats différents?
L'un des fléaux qui m'a le plus - pourquoi Chaîne se comportent comme des primitifs int et non pas comme Integer?

Résultats (java 1.5):

reflection: primitiveInt = 84
direct: primitiveInt = 42
reflection: wrappedInt = 84
direct: wrappedInt = 84
reflection: stringValue = 84
direct: stringValue = 42

cela peut étroitement liés à la compilateur.

InformationsquelleAutor ChssPly76 | 2009-10-23

21

Des constantes de compilation sont inline (à javac au moment de la compilation). Voir la JLS, en particulier 15.28 définit une expression constante et 13.4.9 traite de la compatibilité binaire ou finale, les champs et les constantes.

Si vous faites le domaine de la non-définitive ou d'attribuer un non-compiler constante de temps, la valeur n'est pas insérée. Par exemple:

private final String stringValue = null!=null?"": "42";
- De sorte qu'ils sont. Pour la primitive int j'ai attendu le résultat que j'ai obtenu en retour. C'est la Chaîne qui m'intrigue, c'. Avez-vous un plus concrète lien vers JLS où ce qui est décrit?
- C'est certainement une partie de la réponse, mais comment est-il que si vous avez accès à la chaîne via le champ de réflexion.obtenez vous obtenez une valeur différente que si vous demandez à l'objet directement?
- ChssPly76: Ajouté les deux intéressants articles. Steve B: Si vous utilisez la réflexion, vous retournez à la valeur que l'expression de fichier de classe est définie à ce champ. Si vous faites référence à lui directement, la valeur est copiée à l' (javac) au moment de la compilation (tant que c'est une constante de compilation).
- je vous remercie. Je trouve étrange que JLS accorde un traitement spécial à la Chaîne, mais n'est pas primitive de l'encapsulation en cette matière, mais elle est ce qu'elle est. Constante inline description aurait pu être beaucoup mieux, ça vous ne l'avez pas signalé à l'exact point, je n'aurais jamais trouvé.
- Cela fait presque un sens... sauf voir ma réponse (à paraître).
- Le comportement spécial pour la chaîne vient de la Chaîne de stage. Des chaînes définies au moment de la compilation sont stockées dans une piscine spéciale dans la JVM (que vous pouvez ajouter des chaînes à l'aide d'une Ficelle.stagiaire()). Le compilateur va ensuite traiter la référence à cette internés de la Chaîne comme une constante. Le compilateur a remplacé directement toutes les références à stringValue avec la référence à l'instance unique de "42" qui existe dans les internés des chaînes de la piscine.
InformationsquelleAutor Tom Hawtin - tackline

À mon avis, c'est encore pire: Un collègue m'a fait à la suite de drôle de chose:

@Test public void  testInteger() throws SecurityException,  NoSuchFieldException, IllegalArgumentException, IllegalAccessException  {      
    Field value = Integer.class.getDeclaredField("value");      
    value.setAccessible(true);       
    Integer manipulatedInt = Integer.valueOf(7);      
    value.setInt(manipulatedInt, 666);       
    Integer testInt = Integer.valueOf(7);      
    System.out.println(testInt.toString());
}

En faisant cela, vous pouvez modifier le comportement de l'ensemble de la JVM vous êtes en cours d'exécution.
(bien sûr, vous ne pouvez modifier que les valeurs pour les valeurs entre -127 et 127)

En fait, je pense que les nombres Entiers peuvent avoir une valeur pour la limite supérieure de la cache, de sorte que vous pourrait aller plus haut que ça!
Question d'entrevue 🙂

InformationsquelleAutor GandalfIX

8

Réflexion du set(..) méthode fonctionne avec FieldAccessors.

Pour int il obtient un UnsafeQualifiedIntegerFieldAccessorImpl, dont la super-classe définit la readOnly bien pour être vrai seulement si le champ est les deux static et final

Donc d'abord répondre à la question non formulée - voici pourquoi la final est changé, sans exception.

Toutes les sous-classes de UnsafeQualifiedFieldAccessor utiliser le sun.misc.Unsafe classe pour obtenir les valeurs. Les méthodes y sont tous native, mais leurs noms sont getVolatileInt(..) et getInt(..) (getVolatileObject(..) et getObject(..) respectivement). Ladite accesseurs utiliser le "volatile", version. Voici ce qui se passe si l'on ajoute le non-volatile version:
```
System.out.println("reflection: non-volatile primitiveInt = "
     unsafe.getInt(test, (long) unsafe.fieldOffset(getField("primitiveInt"))));
```
(où unsafe est instancié par la réflexion, il n'est pas permis autrement)
(et j'appelle getObject pour Integer et String)

Qui donne des résultats intéressants:
```
reflection: primitiveInt = 84
direct: primitiveInt = 42
reflection: non-volatile primitiveInt = 84
reflection: wrappedInt = 84
direct: wrappedInt = 84
reflection: non-volatile wrappedInt = 84
reflection: stringValue = 84
direct: stringValue = 42
reflection: non-volatile stringValue = 84
```
À ce point, je me souviens un article à javaspecialists.l'ue de discuter d'un sujet connexe. Il cite La JSR-133:

Si un dernier champ est initialisé à une constante de compilation dans le domaine de déclaration, de modifications à la finale de champ ne peuvent pas être respectées, car les utilisations de ce dernier domaine sont remplacés au moment de la compilation avec la constante de compilation.

Le chapitre 9 décrit les détails observés dans cette question.

Et il s'avère que ce comportement n'est pas inattendu, car les modifications de final champs sont censé arriver juste après l'initialisation de l'objet.
- pour lire le wrappedInt vous pouvez utiliser getObject au lieu de getInt
InformationsquelleAutor Bozho

Ce n'est pas une réponse, mais il apporte un autre point de prêter à confusion:

Je voulais voir si le problème a été au moment de la compilation d'évaluation ou si la réflexion était en fait Java permettant d'obtenir autour de la final mot-clé. Voici un programme de test. Tout ce que je est un autre jeu de getter appels, donc il y a un avant et après chaque changeField() appel.

package com.example.gotchas;
import java.lang.reflect.Field;
public class MostlyFinal {
private final int primitiveInt = 42;
private final Integer wrappedInt = 42;
private final String stringValue = "42";
public int getPrimitiveInt()   { return this.primitiveInt; }
public int getWrappedInt()     { return this.wrappedInt; }
public String getStringValue() { return this.stringValue; }
public void changeField(String name, Object value) throws IllegalAccessException, NoSuchFieldException {
Field field = MostlyFinal.class.getDeclaredField(name);
field.setAccessible(true);
field.set(this, value);
System.out.println("reflection: " + name + " = " + field.get(this));
}
public static void main(String[] args) throws IllegalAccessException, NoSuchFieldException {
MostlyFinal test = new MostlyFinal();
System.out.println("direct: primitiveInt = " + test.getPrimitiveInt());
test.changeField("primitiveInt", 84);
System.out.println("direct: primitiveInt = " + test.getPrimitiveInt());
System.out.println();
System.out.println("direct: wrappedInt = " + test.getWrappedInt());
test.changeField("wrappedInt", 84);
System.out.println("direct: wrappedInt = " + test.getWrappedInt());
System.out.println();
System.out.println("direct: stringValue = " + test.getStringValue());
test.changeField("stringValue", "84");
System.out.println("direct: stringValue = " + test.getStringValue());
}
}

Ici la sortie-je obtenir (sous Eclipse, Java 1.6)

direct: primitiveInt = 42
reflection: primitiveInt = 84
direct: primitiveInt = 42
direct: wrappedInt = 42
reflection: wrappedInt = 84
direct: wrappedInt = 84
direct: stringValue = 42
reflection: stringValue = 84
direct: stringValue = 42

Pourquoi diable ne l'appel direct à getWrappedInt() changement ?

La vraie question est "pourquoi les deux autres ne changent pas?" Et la réponse est: parce que leurs valeurs sont intégrées dans les méthodes de lecture (Tom la réponse de points de JLS sections décrivant ce comportement). Inline ne se produit que pour les types primitifs et de la Chaîne (en supposant que les autres conditions, comme final / expression constante / etc... en sont satisfaits). Donc int et String retour 42 de getters; Entier ne l'est pas. Le réel valeurs ont été modifiées pour tous les 3 champs. Si ceci est source de confusion et il est 🙂 - décompiler la classe et vous verrez ce que je veux dire.

InformationsquelleAutor Jason S

0

Il y a un travail autour de cela. si vous définissez la valeur de la private static final déposé dans la statique {} bloc il va fonctionner car il ne sera pas inline le champ:
```
private static final String MY_FIELD;
static {
MY_FIELD = "SomeText"
}
...
Field field = VisitorId.class.getDeclaredField("MY_FIELD");
field.setAccessible(true);
field.set(field, "fakeText");
```
InformationsquelleAutor Joan P.S

Vous devez vous connecter pour publier un commentaire.