本文主要是介绍答复: 再谈一个关于final的不一致编译的低级错误，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
tlde_ti 写道
我是觉得连依赖管理工具都不用的项目实在算不上 合格的 项目.
维护升级 隐患都非常多.
直接javac只能学习用，进一步说未来学习用也迟早要被 依赖管理自动编译 工具所替代。
维护升级 隐患都非常多.
直接javac只能学习用，进一步说未来学习用也迟早要被 依赖管理自动编译 工具所替代。
这个你只是考虑了自己的一个web项目哦，如果是对外提供服务的lib呢？或者是进行二次开发。。。
这种情况恐怖的是你的jar已经存在很多客户端了。这个时候对常量值的修改将引入一个潜在的bug。。。
skzr.org 写道
tlde_ti 写道
skzr.org 写道
有个疑问，如果依赖关系：
A.jar <-- B.jar <-- C.jar
A: ConstantA.A_CODE=1
B: ConstantB.B_CODE=ConstantA.A_CODE
C: ConstantC.C_CODE=ConstantB.B_CODE
A改变了协议ConstantA.A_CODE=999
那是不是C就抓狂了......
A.jar <-- B.jar <-- C.jar
A: ConstantA.A_CODE=1
B: ConstantB.B_CODE=ConstantA.A_CODE
C: ConstantC.C_CODE=ConstantB.B_CODE
A改变了协议ConstantA.A_CODE=999
那是不是C就抓狂了......
这种情况下应该是B针对A的新版本jar包编译一个新的B,
然后C针对B 新的jar包编译一次.
毕竟这里B使用了A的新版本，应该使用新的A jar包编译一次才对.
这样情况下增量编译也不行了，要先clean才不会出问题。
确实存在这样的问题，如果做服务或者api需要非常小心的处理常量值。
- 提供常量时：接口定义的常量永远不要更改其值——无法绕过这个限制
- 提供常量时：类中定义的常量放在初始化块中初始化中进行初始化，而不是直接一个=完事——不会出现这个限制
- 使用常量时：外部的常量尽量不要再在内部定义另一个常量别名，如果非要定义采用第二条
来源 主题：再谈一个关于final的不一致编译的低级错误
这篇关于答复: 再谈一个关于final的不一致编译的低级错误的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
