|
精华帖 (0) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-09-24
kjj 写道 我觉得你们过滤了，java类文件之间本来就是一个整体，是你们刻意把单独的拿出来，才导致这样的问题，类之间本来就是有逻辑关系的，而不能割裂开来看
哈哈哈 你可以从回复中看到 如果不采用如项目管理/依赖管理工具 问题总会有人碰到 |
| 返回顶楼 | |
|
发表时间：2012-09-25
最后修改：2012-09-25
我是觉得连依赖管理工具都不用的项目实在算不上 合格的 项目.
维护升级 隐患都非常多. 直接javac只能学习用，进一步说未来学习用也迟早要被 依赖管理自动编译 工具所替代。 |
| 返回顶楼 | |
|
发表时间：2012-09-25
tlde_ti 写道 我是觉得连依赖管理工具都不用的项目实在算不上 合格的 项目.
维护升级 隐患都非常多. 直接javac只能学习用，进一步说未来学习用也迟早要被 依赖管理自动编译 工具所替代。 话说是这样  可实际是种种情况都会发生。
|
| 返回顶楼 | |
|
发表时间：2012-09-25
最后修改：2012-09-25
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. 使用常量时：外部的常量尽量不要再在内部定义另一个常量别名，如果非要定义采用第二条 |
| 返回顶楼 | |
|
发表时间：2012-09-25
最后修改：2012-09-25
这个你只是考虑了自己的一个web项目哦，如果是对外提供服务的lib呢？或者是进行二次开发。。。
这种情况恐怖的是你的jar已经存在很多客户端了。这个时候对常量值的修改将引入一个潜在的bug。。。 ----------------- 对外提供服务的Lib也是一样的，他用新版本的jar，至少要重新编译一次。我在这里改代码容忍他随意丢jar包上服务器，他迟早会在其它类库上遇上同样的问题. 用等号就了事是直觉的，程序员应对代码应该尽量懒惰，换句话说，我认为这是 自动化工具的任务，程序员尽量不要手动做底层的事. 另外我回的第一个帖子已经说了，这是编译器符合逻辑而应有的优化，因为环境的异常(注1)导致逻辑条件不成立而手动阻止这种符合逻辑的优化却不是去保证正常逻辑成立的条件，我是不能理解的（注2）. 先总结两条做法 1.使用新的jar时,依赖管理工具获取相应版本dependency jar包，自己先clean,再编译 2.自己的代码变化，使用增量编译,不要Javac. (注1)例如直接丢新Jar和javac后的文件上服务器 (注2)配置文件的理由我能接收，因为配置文件的主要目的是其它的东西. |
| 返回顶楼 | |
|
发表时间：2012-09-25
升级第三方jar有时候只是为了使用新版本，因为
1. 本身服务接口api并未发生改变 2. 本身程序运行很稳定 升级jar是因为新jar的性能提升，新jar解决了某些bug。 所以这个时候工程不会重新package。 |
| 返回顶楼 | |
|
发表时间：2012-09-25
这个还没怎么注意，感谢lz！
|
| 返回顶楼 | |
|
发表时间：2012-09-25
这个问题我也遇见过 基本上要把相关类全都更新一遍就差不多了 主要根据编译后的calss文件的日期来判断
|
| 返回顶楼 | |
|
发表时间：2012-10-07
标题应该叫编译优化的陷阱 更贴切
|
| 返回顶楼 | |
|
发表时间：2012-10-07
冲杯茶喝 写道 标题应该叫编译优化的陷阱 更贴切
|
| 返回顶楼 | |
