javac -parameters 标志的缺点 [英] Drawbacks of javac -parameters flag
问题描述
我想尝试一些在运行时需要参数名称的框架功能，所以我需要使用 -parameters 编译我的应用程序，它会将参数名称存储在 JVM 字节码中.
这个参数使用除了jar/war的大小还有什么缺点?
JEP 118，它是在 Java 8 中交付的.有一些关于为什么在 OpenJDK 电子邮件线程中包含参数名称是可选的讨论这里 和 此处.简而言之，将参数名称设为可选的所述原因是担心类文件大小、兼容性表面和敏感信息的暴露.
兼容性表面的问题值得进一步讨论.上面链接的一个线程说更改参数名称是二进制兼容的更改.这是真的，但仅在 JVM 的二进制兼容性概念的严格上下文中.也就是说，更改方法的参数名称永远不会改变该方法是否可以被 JVM 链接.但该声明通常不适用于兼容性.
过去，参数名称被视为局部变量名称.(毕竟，它们在范围内是局部的.)您可以随意更改它们，方法之外的任何内容都不会受到影响.但是，如果您启用对参数名称的反射访问，您将无法在不考虑程序的其他部分可能正在使用它的情况下更改名称.更糟糕的是，除非您对所有参数名称的使用都有严格的测试用例，否则没有什么可以告诉您的，或者您有一个非常好的静态分析器可以找到这些用例(我不知道有一个).
评论链接到有关使用 Jackson(一个 JSON 处理库)的问题，该问题具有将方法参数名称映射到 JSON 属性名称的功能.这可能很方便，但这也意味着如果您更改参数名称，JSON 绑定可能会中断.更糟糕的是，如果程序基于 Java 方法参数名称生成 JSON 结构，那么更改方法参数名称可能会悄悄更改数据格式或有线协议.显然，在这样的环境中，可靠地使用此功能意味着您必须进行非常好的测试，并在代码周围散布注释，指示哪些参数名称不得更改.
I want to try some frameworks features that required names of parameter in runtime, so I need to compile my app with -parameters and it will store the names of parameter in JVM byte code.
Which drawbacks except the size of jar/war exist of this parameter usage?
The addition of parameter names to the class file format is covered by JEP 118, which was delivered in Java 8. There was a little bit of discussion about why inclusion of parameter names was made optional in OpenJDK email threads here and here. Briefly, the stated reasons to make parameter names optional are concerns about class file size, compatibility surface, and exposure of sensitive information.
The issue of compatibility surface deserves some additional discussion. One of the threads linked above says that changing a parameter name is a binary compatible change. This is true, but only in the strict context of the JVM's notion of binary compatibility. That is, changing a parameter name of a method will never change whether or not that method can be linked by the JVM. But the statement doesn't hold for compatibility in general.
Historically, parameter names have been treated like local variable names. (They are, after all, local in scope.) You could change them at will and nothing outside the method will be affected. But if you enable reflective access to parameter names, suddenly you can't change a name without thinking about what other parts of the program might be using it. Worse, there's nothing that can tell you unless you have strict test cases for all uses of parameter names, or you have a really good static analyzer that can find these cases (I'm not aware of one).
The comments linked to a question about using Jackson (a JSON processing library) which has a feature that maps method parameter names to JSON property names. This may be quite convenient, but it also means that if you change a parameter name, JSON binding might break. Worse, if the program is generating JSON structures based on Java method parameter names, then changing a method parameter name might silently change a data format or wire protocol. Clearly, in such an environment, using this feature reliably means that you have to have very good tests, plus comments sprinkled around the code indicating what parameter names mustn't be changed.
这篇关于javac -parameters 标志的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
