Typage : Object vers MonObjet

Bonjour,

J'utilise une sérialisation AMF pour échanger des objets entre un module Flex et une application Java.
Lors de la désérialisation, j'obtiens un objet de type Object que je caste en MonObjet (connu mais pouvant être n'importe quoi héritant de Object). Lors de ce cast, j'obtiens un warning tout ce qu'il y a de plus compréhensible ("Type safety: Unchecked cast from Object to T")... mais que je ne vois pas du tout comment corriger.

Ça fonctionne, mais s'il y a un warning, c'est qu'il y a probablement quelque chose de plus élégant à faire.

Y a-t-il une solution de "blindage" générique ?

Le code de la méthode incriminée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

try { final byte[] input = dec.decode(amf); final InputStream bIn = new ByteArrayInputStream(input); final Amf3Input amf3Input = new Amf3Input(getSerializationContext()); amf3Input.setInputStream(bIn); T obj = (T) amf3Input.readObject(); // Et là, ça couine. return obj; } catch (final IOException e) { // Hop hop. } catch (final ClassNotFoundException e) { // Hop hop aussi. }

---

Merci !

Alban

Salut,


Le problème vient du fait que les casts s'associent mal avec les Generics.

:arrow: Les Generics te garantissent un code sans erreur de type, grâce au compilateur qui a la charge de vérifier la cohérence du typeage de ton code.

Or les casts peuvent engendrer des erreurs à l'exécution. De plus comme le code des Generics est "perdu", il y a certains casts qui n'en sont pas réellement et qui sont en fait exécuté plus tard.

Bref si tu mélanges des casts et du code Generics, le compilateur ne peut plus assurer la cohérence de l'ensemble, et il t'indique cela via ce warning.



Si tu es parfaitement sûr de toi, tu peux utiliser l'annotation @SuppressWarnings pour indiquer au compilateur que tu comprends le problème et que tu prends cela en charge :

Code:

---

1 2	@SuppressWarnings("unchecked") T obj = (T) amf3Input.readObject();

---

a++

Merci pour les précisions.

Pour tout dire, je suis sûr de l'utilisation que je vais faire de ce code, je suis sûr du code lui-même (il est testé et éprouvé)... mais j'aimerais autant éviter à mes gentils collègues de mettre le pied dans un piège à loup si je peux l'éviter.

Ceci dit, je suis prêt à ne pas utiliser les génériques s'il y a un autre moyen (simple ou presque) de le faire. Sinon, je taperai dans le suppressWarnings... ça ne sera pas la première fois (même si ça me fait toujours mal au coeur ;) ).

Il faudrait voir le code de la méthode entière... mais en général ce n'est pas bien méchant.

Ici le problème est déplacé de quelque ligne :

Code:

---

1 2	T obj = (T) amf3Input.readObject(); return obj;

---

:arrow: En cas de type incorrect, il n'y aura pas de ClassCastException sur le cast, mais uniquement après le retour de la méthode...

a++

En fait, toute la méthode est là. C'est une méthode utilitaire qui se tape la conversion.

Ma requête HTTP contient l'objet en AMF (encodé en base 64), c'est le paramètre d'entrée de la méthode (String amf) et je renvoie l'objet désérialisé de type T :

Code:

---

MonObjet obj = AmfUtil.<MonObjet> fromAmf(amf); // Avec la-dedans le code ci-dessus

---

Je voulais avoir toute la méthode, avec sa signature exacte.


Je suppose que tu as quelques chose comme cela :

Code:

---

public <T> T method()

---

Le problème c'est qu'en cas d'usage incorrect, tu peux te trimballer un T avec un type incorrect, et qui risque de te péter à la figure bien plus loin dans le code, et de manière totalement inattendu.

Pour sécuriser cela il faudrait rajouter le type Class<T> en paramètre, afin de faire un cast sécurisé :

Code:

---

public <T> T method(Class<T> baseClazz)

---

Puis :

Code:

---

1 2	T obj = baseClazz.cast( amf3Input.readObject() ); return obj;

---

:arrow: Ce qui a le mérite de te péter à la gueule tout de suite en cas de soucis ;)


a++

Voilà quelque chose qui me plaît bien :)
C'est implémenté, ça marche et finis les warnings.

Merci !

Ah ah ah, presque ! Ca marche bien... sauf pour les generics.
Un appel comme celui-ci ne fonctionne pas :

Code:

---

final List<MonObjet> maListe = AmfUtil.<ArrayList<MonObjet>> fromAmf(source, ?????);

---

J'ai bien essayé de tricher avec le typage :

Code:

---

final List<MonObjet> maListe = AmfUtil.<ArrayList<MonObjet>> fromAmf(source, (new ArrayList<MonObjet>()).getClass());

---

m'enfin c'est pas mieux.

Citation:

---

The parameterized method <ArrayList<MonObjet>>fromAmf(String, Class<ArrayList<MonObjet>>) of type AmfUtil is not applicable for the arguments (String, Class<capture#1-of ? extends ArrayList>)

---

La méthode utilisée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public static <T> T fromAmf(final String amf, final Class<T> baseClass) throws SystemException { final Base64 dec = new Base64(); try { final byte[] input = dec.decode(amf); final InputStream bIn = new ByteArrayInputStream(input); final Amf3Input amf3Input = new Amf3Input(getSerializationContext()); amf3Input.setInputStream(bIn); final T obj = baseClass.cast(amf3Input.readObject()); return obj; } catch (final IOException e) { throw new SystemException(e.getMessage(), e); } catch (final ClassNotFoundException e) { throw new SystemException(e.getMessage(), e); } }

---

Je me sens un peu boulet sur ce coup...

Le problème avec les types paramétrés, c'est qu'il n'est pas possible de garantir le typeage exact à l'exécution.

Dans ton cas tu peux seulement contrôler le "raw type" de l'objet, c'est à dire List, mais en aucun cas le typeage précis (List<MonObjet>).

En gros il faudrait passer par une version non-typé (List<?> avec List.class):

Code:

---

final List<?> maListe = AmfUtil.fromAmf(source, List.class);

---

Après bien sûr tu peux typer un peu plus fortement en remplaçant le List<?> par un List<MonObjet>, mais tu n'a aucune garantie que le type soit bien correct. D'ailleurs le compilateur te le signalera par un warning que tu peux ignorer seulement si tu es sûr de ton coup :

Code:

---

1 2	@SuppressWarnings("unchecked") final List<MonObjet> maListe = AmfUtil.fromAmf(source, List.class);

---

:arrow: Le problème c'est que tu n'auras aucune erreur ni exception si tu récupère un mauvais type (par exemple si ce que tu récupère correspond en réalité à une List<String>).
Tout se passera normalement à la lecture... mais cela pourrait provoquer des erreurs incompréhensible plus tard lorsque tu utiliseras ta liste.


a++

Dans ces cas-là, ce que je fais, c'est une autre méthode, dédiée aux listes. C'est moins générique mais ça vérifie bien le typage, et des cas comme celui-ci on n'en a pas non plus soixante.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public static <T> List<T> listFromAmf(String amf, Class<T> eltClass) { //... // choper la liste List<?> list = (List<?>)amf3Input.readObject(); // verifier le type des éléments for(Object element : list) { eltClass.cast(element); } // éléments ok : typer la liste, et dire au compilateur de pas s'inquiéter @SuppressWarnings("unchecked") List<T> tList = (List<T>)list; return tList; }

---

@thelvin : bonne idée mais pourquoi ne pas externaliser cela :

Code:

---

1 2 3 4 5 6 7 8

public static <E, C extends Collection<E>> C cast(Collection<?> collection, Class<E> elementType) { for (Object o : collection) { elementType.cast(o); } @SuppressWarnings("unchecked") C checkedCollection = (C) collection; return checkedCollection; }

---

Code:

---

List<MonObjet> maListe = cast(fromAmf(source, List.class), MonObjet.class);

---

Non ?!?

a++

Argh, j'arrive tard !
Entre temps, j'avais créé une méthode spécifique pour les listes en passant par une liste tampon :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public static <T> List<T> listFromAmf(final String amf, final Class<T> baseClass) throws SystemException { List<?> tempList; final List<T> retList = new ArrayList<T>(); try { final Amf3Input amf3Input = getAmf3InputFromString(amf); tempList = (List<?>) amf3Input.readObject(); for (final Object o : tempList) { if (o instanceof DtObject) { retList.add(baseClass.cast(DtUtil.cloneObjectWoNull((DtObject) o))); } else { retList.add(baseClass.cast(o)); } } return retList; } catch (final IOException e) { throw new SystemException(e.getMessage(), e); } catch (final ClassNotFoundException e) { throw new SystemException(e.getMessage(), e); } }

---

Ca recoupe pas mal ta solution, thelvin, à ceci près que tu n'utilises qu'une seule liste (à voir ce qui est le mieux).
Merci à tous les deux, je pense qu'avec tout ça, je devrais m'en sortir !