Possible pollution du tas via le paramètre varargs

Question

Je comprends que cela se produit avec Java 7 lors de l'utilisation de varargs avec un type générique;

Mais ma question est..

Que signifie exactement Eclipse quand il dit que "son utilisation pourrait potentiellement polluer le tas?"

Et

Comment la nouvelle annotation @SafeVarargs empêche-t-elle cela?

Answer 1

La pollution de la heap est un terme technique. Il fait référence à des références qui ont un type qui n'est pas un supertype de l'objet auquel elles pointent.

List listOfAs = new ArrayList<>();
List listOfBs = (List)(Object)listOfAs; // points to a list of As

---

Cela peut entraîner des ClassCastException "inexpliquées".

// if the heap never gets polluted, this should never throw a CCE
B b = listOfBs.get(0); 

@SafeVarargs ne prévient pas du tout cela. Cependant, il existe des méthodes qui ne pollueront pas la heap, le compilateur ne peut tout simplement pas le prouver. Auparavant, les appelants de ces API recevaient des avertissements agaçants complètement inutiles mais devaient les supprimer à chaque site d'appel. Maintenant, l'auteur de l'API peut le supprimer une fois au niveau de la déclaration.

Cependant, si la méthode n'est en fait pas sûre, les utilisateurs ne seront plus avertis.

---

Answer 2

Lorsque vous déclarez

public static void foo(List... bar) le compilateur le convertit en

public static void foo(List[] bar) puis en

public static void foo(List[] bar)

Le danger survient alors que vous pourriez assigner par erreur des valeurs incorrectes à la liste et le compilateur ne déclenchera aucune erreur. Par exemple, si T est une String alors le code suivant compilera sans erreur mais échouera à l'exécution:

// Premièrement, retirez le type de tableau (les tableaux permettent ce genre de conversion ascendante)
Object[] objectArray = bar;

// Ensuite, insérez un élément avec un type incorrect dans le tableau
objectArray[0] = Arrays.asList(new Integer(42));

// Enfin, essayez d'accéder au tableau original. Une erreur d'exécution se produira
// (ClassCastException due à une conversion de Integer en String)
T firstElement = bar[0].get(0);

Si vous avez vérifié la méthode pour vous assurer qu'elle ne contient pas de failles de sécurité de ce genre alors vous pouvez l'annoter avec @SafeVarargs pour supprimer l'avertissement. Pour les interfaces, utilisez @SuppressWarnings("unchecked").

Si vous obtenez ce message d'erreur:

La méthode varargs pourrait causer de la pollution de la mémoire à partir du paramètre varargs non reifiable

et que vous êtes certain que votre utilisation est sécuritaire alors vous devriez utiliser @SuppressWarnings("varargs") à la place. Voir Is @SafeVarargs an appropriate annotation for this method? et https://stackoverflow.com/a/14252221/14731 pour une explication détaillée de ce deuxième type d'erreur.

Références:

• http://docs.oracle.com/javase/7/docs/technotes/guides/language/non-reifiable-varargs.html
• http://docs.oracle.com/javase/tutorial/java/generics/nonReifiableVarargsType.html#heap_pollution

Answer 3

@SafeVarargs ne l'empêche pas de se produire, mais il impose que le compilateur soit plus strict lors de la compilation du code qui l'utilise.

http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html explique cela plus en détail.

La pollution du tas se produit lorsque vous obtenez une ClassCastException en effectuant une opération sur une interface générique et qu'elle contient un autre type que celui déclaré.

Answer 4

Lorsque vous utilisez varargs, cela peut entraîner la création d'un Object[] pour contenir les arguments.

Grâce à l'analyse des échappements, le JIT peut optimiser la création de ce tableau. (Une des rares fois où je l'ai constaté) Il n'est pas garanti qu'il soit optimisé, mais je ne m'en préoccuperais pas sauf si vous constatez que c'est un problème dans votre profileur de mémoire.

AFAIK @SafeVarargs supprime un avertissement du compilateur et ne modifie pas le comportement du JIT.

Answer 5

La raison est que varargs donne l'option d'être appelé avec un tableau d'objets non paramétré. Donc si votre type était List < A > ... , il peut aussi être appelé avec le type non-varargs List[].

Voici un exemple:

public static void testCode(){
    List[] b = new List[1];
    test(b);
}

@SafeVarargs
public static void test(List... a){
}

Comme vous pouvez le voir, List[] b peut contenir n'importe quel type de consommateur, et pourtant ce code se compile. Si vous utilisez varargs, alors vous êtes bon, mais si vous utilisez la définition de méthode après l'effacement de type - void test(List[]) - alors le compilateur ne vérifiera pas les types des paramètres du modèle. @SafeVarargs supprimera cet avertissement.