答复: 再谈一个关于final的不一致编译的低级错误

tlde_ti 写道

我是觉得连依赖管理工具都不用的项目实在算不上 合格的 项目.
维护升级 隐患都非常多.

直接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就抓狂了......

这种情况下应该是B针对A的新版本jar包编译一个新的B,
然后C针对B 新的jar包编译一次.
毕竟这里B使用了A的新版本，应该使用新的A jar包编译一次才对.

这样情况下增量编译也不行了，要先clean才不会出问题。

 

确实存在这样的问题，如果做服务或者api需要非常小心的处理常量值。

1. 提供常量时：接口定义的常量永远不要更改其值——无法绕过这个限制
2. 提供常量时：类中定义的常量放在初始化块中初始化中进行初始化，而不是直接一个=完事——不会出现这个限制
3. 使用常量时：外部的常量尽量不要再在内部定义另一个常量别名，如果非要定义采用第二条

来源 主题：再谈一个关于final的不一致编译的低级错误