Inconvénients de javac -parameters flag

Question

Je veux essayer certaines fonctionnalités de frameworks qui nécessitent des noms de paramètres en runtime, donc j'ai besoin de compiler mon application avec -parameters et il va stocker les noms de paramètres dans le code octet JVM.

Quels sont les inconvénients, à l'exception de la taille du bocal/guerre, de l'utilisation de ce paramètre?

Answer 1

L'ajout de noms de paramètres au format de fichier de classe est couvert par JEP 118, qui a été livré en Java 8. Il y avait un peu de discussion sur les raisons de l'inclusion des noms de paramètres a été rendu facultatif fils de discussion OpenJDK here et here. Brièvement, les raisons indiquées pour rendre les noms de paramètres facultatifs sont les préoccupations concernant la taille du fichier de classe, la surface de compatibilité et l'exposition d'informations sensibles.

La question de la compatibilité de la surface mérite une discussion supplémentaire. L'un des threads liés ci-dessus indique que la modification d'un nom de paramètre est une modification compatible binaire. C'est vrai, mais seulement dans le contexte strict de la notion de compatibilité binaire de la JVM. En d'autres termes, la modification d'un nom de paramètre d'une méthode ne changera jamais, que cette méthode puisse être liée ou non par la JVM. Mais la déclaration ne tient pas pour la compatibilité en général.

Historiquement, les noms de paramètres ont été traités comme des noms de variables locales. (Ils sont, après tout, de portée locale.) Vous pouvez les changer à volonté et rien en dehors de la méthode ne sera affecté. Mais si vous activez l'accès réfléchi aux noms de paramètres, vous ne pouvez plus changer de nom sans penser aux autres parties du programme qui pourraient l'utiliser. Pire, il n'y a rien qui puisse vous dire à moins que vous ayez des cas de test stricts pour toutes les utilisations de noms de paramètres, ou que vous ayez un très bon analyseur statique capable de trouver ces cas (je n'en connais pas).

Les commentaires liés à une question sur l'utilisation de Jackson (une bibliothèque de traitement JSON) qui a une fonction qui mappe les noms de paramètres de méthode aux noms de propriété JSON. Cela peut être très pratique, mais cela signifie également que si vous modifiez un nom de paramètre, la liaison JSON risque de se casser. Pire, si le programme génère des structures JSON basées sur des noms de paramètres de méthode Java, la modification d'un nom de paramètre de méthode peut modifier silencieusement un format de données ou un protocole filaire. De toute évidence, dans un tel environnement, l'utilisation de cette fonctionnalité signifie que vous devez avoir de très bons tests, ainsi que des commentaires saupoudrés autour du code indiquant quels noms de paramètres ne doivent pas être modifiés.

Answer 2

Le ne chose est la taille de la .class qui changera, puisque le bytecode contiendra plus d'information:

public class DeleteMe3 { 
    public static void main(String[] args) { 
    } 

    private static void go(String s) { 
    } 
} 

Par exemple, cela contiendra des informations sur les noms de paramter comme ceci:

private static void go(java.lang.String); 
    descriptor: (Ljava/lang/String;)V 
    flags: ACC_PRIVATE, ACC_STATIC 
    Code: 
    stack=0, locals=1, args_size=1 
     0: return 
    LineNumberTable: 
     line 11: 0 
    MethodParameters: 
    Name       Flags 
    s 

Ce MethodParameters ne sera simplement pas présent sans -parameters.

Il peut y avoir des frameworks qui ne sont pas sympas avec ça. En voici un Spring Data JPA Issue. Je le sais parce que nous l'avons frappé il y a un certain temps et que nous devions le mettre à niveau (je n'ai pas été confronté à d'autres à partir de là).