16 | 改进的废弃,怎么避免使用废弃的特性?
范学雷
你好,我是范学雷。今天,我们讨论 Java 公开接口的废弃。
像所有的事物一样,公开接口也有生命周期。要废弃那些被广泛使用的、或者还有人使用的公开接口,是一个非常痛苦的过程。该怎么废弃一个公开接口,该怎么减少废弃接口对我们的影响呢?这是这一次我们要讨论的话题。
我们先来看看阅读案例。
阅读案例
在 JDK 中,一个公开的接口,可能会因为多种多样的原因被废弃。比如说,这个接口的设计是危险的,或者有了更新的、更好的替代接口。不管是什么原因,废弃接口的使用者们都需要尽快迁移代码,转换到替代方案上来。
在 JDK 中,公开接口的废弃需要使用两种不同的机制,也就是“Deprecated” 注解(annotation)和“Deprecated”文档标记(JavaDoc tag)。
Deprecated 的注解会编译到类文件里,并且可以在运行时查验。这就允许像 javac 这样的工具检测和标记已废弃接口的使用情况了。
Deprecated 文档标记用于描述废弃接口的文档中。除了标记接口的废弃状态之外,一般情况下,我们还要描述废弃的原因和替代的方案。
下面的这段代码,就是使用 Java 注解和文档标记来废弃一个公开接口的例子。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
JDK 9中的Java公开接口废弃过程经历了重大改进,使得废弃接口的管理变得更加高效。文章介绍了废弃接口的现实问题和改进的三部曲。其中,新增了jdeprscan工具用于扫描编译好的Java类或包,即使代码使用了SuppressWarnings注解,也不受影响。同时,给Deprecated注解增加了"forRemoval"和"since"属性,提供了删除计划和废弃时间的信息,强调了代码迁移的紧急性。对于接口的使用者和维护者,需要按照废弃的三部曲有序推进,尽快完成代码迁移。总的来说,要管理好废弃的接口,遵守程序,有序推进,做好计划,尽快完成代码迁移,并使用好新增的工具。文章还提出了一个思考题,让读者练习接口废弃的过程,以及对代码进行修改。整体而言,本文深入探讨了Java公开接口废弃的复杂性,并介绍了JDK 9中的重大改进,对于Java开发者具有一定的参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Java 新特性》,新⼈⾸单¥59
《深入剖析 Java 新特性》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
- aoe大部分项目自身的Bug数远远超过废弃接口可能带来的Bug,所以很难及时清理。
作者回复: 没太了解这个逻辑
2021-12-2224 - Jxin更不更换废弃接口,跟工具本身关系其实不大。强行废弃不见得能推动使用方变更,反而更容易让他们不敢再更新版本,毕竟够用。 为什么这么说?因为更换废弃接口这件事,对业务毫无价值,业务一定不买单;对开发者个人成长和业绩也毫无帮助,所以单这件事开发者本身也不买单;有变更就会有风险,所以变更必须测试验证,验证有成本,所以换废弃接口即有风险也有成本。综上所述,百害而无一利的局面,不动就是最优解。 那怎么破局?首先不是所有局都该破,我们是在有限的资源下开发,只要确定不会有损失,或则损失可控,选择不变就是合理的。但是这建立在一个脆弱的前提上,就是我们能够准确识别危机(黑天鹅)。所以我觉得,为了成本不是所有局都要去破,但对于可能发散发展的危机要保持敏感和警惕。接下来就是怎么做了,如果更换废弃接口本身无利可图,那就把它跟有利可图的事打包一起来看。比如,系统优化升级必须完成涉及服务的废弃接口更换。系统优化是有利于个人成长且对晋升有帮助的事项,打包一起后就也能依托这份利益对开发者的驱动力。
作者回复: 唉,老大难问题。
2021-12-311 - xiaobang非jdk库的接口也可以使用这种废弃机制吗?
作者回复: 是的
2021-12-222 - ifelse学习打卡2022-10-14归属地:浙江
- ABC在Object.java里面就有例子, finalize()方法就是在JDK9被废弃了,而且forRemoval=true,具体可以看看: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java#L5762021-12-26
收起评论