Comment supprimer des types d'implémentation de la stratégie de sérialisation de GWT?

Question

Le contraire de cette question: How do I add a type to GWT's Serialization Policy whitelist?

GWT ajoute des types non désirés à la politique de sérialisation et gonfle mon JS. Comment découper ma liste blanche GWT à la main? Ou devrais-je du tout? Par exemple, si je place l'interface List sur une classe de service GWT RPC, GWT doit générer un Javascript qui gère ArrayList, LinkedList, Stack, Vector, ... même si mon équipe sait que nous n'allons jamais que retourne une ArrayList. Je pourrais juste faire le retour de la méthode de type ArrayList, mais j'aime me fier à une interface plutôt qu'à une implémentation spécifique. Après tout, peut-être un jour nous allons le changer et revenir par exemple. une LinkedList. Dans ce cas, je voudrais forcer la stratégie de sérialisation GWT à compiler uniquement pour ArrayList et LinkedList. Pas de piles ou de vecteurs.

Ces restrictions implicites ont un énorme inconvénient que je peux penser: un nouveau membre de l'équipe commence à retourner des vecteurs, ce qui sera une erreur d'exécution. Donc, en plus de la question dans le titre, quelle est votre expérience de conception autour de cela?

Answer 1

Il existe une propriété qui peut faire cette liste noire de classe. Par exemple, à la liste noire non ArrayList Collections, ajoutez ces lignes à votre * .gwt.xml:

<extend-configuration-property name="rpc.blacklist" value="java.util.HashSet"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.LinkedHashSet"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.LinkedList"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.Stack"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.TreeMap"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.TreeSet"/> 
<extend-configuration-property name="rpc.blacklist" value="java.util.Vector"/> 

Cela me était nécessaire de réduire la taille JS lors de l'envoi d'objets intégré dans GWT com.google.gwt.user.client.ui.SuggestOracle$Response sur le fil. Ces objets contiennent un java.util.Collection, mais je savais que je ne ferais que renvoyer une ArrayList. Je respecte toujours les avantages des contrôles à la compilation comme discuté dans les autres réponses, commentaires, et ma question initiale. En effet, c'est une solution floconneuse si GWT commence à ramasser des implémentations supplémentaires à sérialiser (pourquoi n'est-ce pas une liste blanche?). Cependant, cette propriété "rpc.blacklist" m'a évité de lancer le mien SuggestOracle juste pour obtenir un type de collection plus spécifique.

Answer 2

Alors qu'aucun framework ne devrait jamais essayer de changer ses utilisateurs, laissez-moi essayer d'expliquer pourquoi la sérialisation de GWT fonctionne comme elle le fait. Je ne connais pas la mécanique exacte de cela, donc je peux me tromper, mais c'est l'essentiel de ce que j'ai vu. GWT supprime déjà le code supplémentaire en dehors des interfaces RPC - par exemple, si vous prenez une application sans RPC, vous êtes libre d'utiliser des interfaces comme List et Map et Set to your hearts - GWT inclura automatiquement le implémentations que vous utilisez réellement. Pourquoi? Parce qu'il a accès à votre code, et qu'il est capable de parcourir toutes les permutations visibles du code et d'élaguer les classes inutilisées. GWT ne crée donc pas d'explosions de classe lorsque des interfaces sont utilisées.

Le problème est entièrement le RPC. Le point d'un service RPC est que le serveur doit implémenter une interface RPC - ce qui signifie que si l'interface dicte qu'une méthode doit renvoyer une liste, le serveur est libre de retourner toute implémentation de la liste qu'il souhaite, aussi longtemps comme il peut être sérialisé.

C'est le problème - GWT n'a absolument aucun moyen de savoir quelle implémentation d'une interface un serveur utilisera, soit au moment de la compilation, soit à un moment donné dans le futur. Le code serveur peut, et dans de nombreux cas, être développé indépendamment du code côté client. Ainsi, la seule façon de recevoir en toute sécurité un objet de type List sur le fil est de connaître au préalable toutes les implémentations possibles.