欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-05-22 09:46:43
...
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的不一致编译的低级错误
            
    
    博客分类: J2EE  

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