我想尝试一些在运行时需要参数名称的框架功能，因此我需要使用以下命令来编译我的应用程序-parameters它将参数的名称存储在 JVM 字节码中。
除了jar/war的大小之外，该参数的使用还有哪些缺点？
将参数名称添加到类文件格式的内容包含在JEP 118 http://openjdk.java.net/jeps/118，这是在 Java 8 中交付的。关于为什么在 OpenJDK 电子邮件线程中包含参数名称是可选的，有一些讨论here http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html and here http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html。简而言之，将参数名称设置为可选的原因是出于对类文件大小、兼容性表面和敏感信息暴露的考虑。
兼容性表面的问题值得一些额外的讨论。上面链接的线程之一说更改参数名称是二进制兼容的更改。这是事实，但仅限于 JVM 二进制兼容性概念的严格上下文中。也就是说，更改方法的参数名称永远不会改变该方法是否可以被 JVM 链接。但该声明并不适用于一般兼容性。
从历史上看，参数名称被视为局部变量名称。 （毕竟，它们的范围是本地的。）您可以随意更改它们，方法之外的任何内容都不会受到影响。但是，如果您启用对参数名称的反射访问，突然间您就无法在不考虑程序的其他部分可能正在使用该名称的情况下更改名称。更糟糕的是，没有什么可以告诉您，除非您对参数名称的所有使用都有严格的测试用例，或者您有一个非常好的静态分析器可以找到这些情况（我不知道有这样一个）。
这些评论链接到有关使用 Jackson（一个 JSON 处理库）的问题，Jackson 具有将方法参数名称映射到 JSON 属性名称的功能。这可能非常方便，但这也意味着如果更改参数名称，JSON 绑定可能会中断。更糟糕的是，如果程序基于 Java 方法参数名称生成 JSON 结构，则更改方法参数名称可能会默默地更改数据格式或线路协议。显然，在这样的环境中，可靠地使用此功能意味着您必须进行非常好的测试，并且在代码周围添加注释，指示哪些参数名称不得更改。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
