只做衬衣网站,网站推广策划的策略,招聘58同城找工作,化学网站定制维护API很难。 我们正在维护非常复杂的jOOQ API。 但是就语义版本而言#xff0c;我们遵循相对宽松的规则 。 当您阅读Brian Goetz和其他人关于在JDK中保持向后兼容性的评论时#xff0c;我只能对他们的工作表示敬意。 显然#xff0c;我们都希望最终移除Vector #xff… 维护API很难。 我们正在维护非常复杂的jOOQ API。 但是就语义版本而言我们遵循相对宽松的规则 。 当您阅读Brian Goetz和其他人关于在JDK中保持向后兼容性的评论时我只能对他们的工作表示敬意。 显然我们都希望最终移除Vector Stack Hashtable类的东西但是在collection API周围存在与向后兼容相关的边缘情况普通凡人不会想到。 例如 Java集合为什么不删除通用方法 更好的弃用 Stuart Marks又名Dr Deprecator 使用Java 9Jigsaw和模块化这些新功能的主要驱动目标之一是能够“切断” JDK的各个部分并在以后的发行版中轻轻地弃用并删除它们。 作为此改进的一部分 Stuart Marks AKA Deprecator博士建议了JEP 277“增强的弃用” 。 这样做的目的是通过一些附加信息来增强Deprecated批注例如 不确定的 。 该API已被弃用没有给出任何理由。 这是默认值; 今天隐含弃用的所有内容都有一个不赞成使用的弃用原因。 谴责 。 该API已指定在将来的JDK版本中删除。 请注意此处使用的“已谴责”一词在意欲拆除的结构的意义上使用。 该术语并不意味着暗示任何道德谴责。 危险的 。 使用此API可能导致数据丢失死锁安全漏洞错误结果或JVM完整性丢失。 过时的 。 不再需要此API应删除用法。 不存在替代API。 请注意OBSOLETE API可能会或可能不会标记为CONDEMNED。 放弃 。 该API已被较新的API取代用法应从该API迁移到较新的API。 请注意SUPERSEDED API可能会或可能不会被标记为CONDEMNED。 已取消 。 调用无效或将无条件引发异常。 实验 。 该API并不是规范的稳定部分它可能会不兼容地更改或随时消失。 在弃用东西时能够传达弃用的意图很重要。 也可以通过deprecated Javadoc标记来实现该标记可以生成任何类型的文本。 另一种更好的解决方案 上述主张存在以下问题 它是不可扩展的 。 对于JDK库设计人员来说以上内容可能就足够了但是作为第三方API提供程序的我们将希望枚举中包含更多元素而不是CONDEMNEDDANGEROUS等。 仍然没有纯文本信息 。 由于我们仍无法正式向注释提供任何可澄清的文本例如为什么某事物“危险”的动机因此该注释与Javadoc标记之间仍然存在冗余。 “不推荐使用”是错误的 。 将UNIMPLEMENTED或EXPERIMENTAL标记为“已弃用”的想法表明了该JEP的变通方法性质它试图在现有名称中增加一些新功能。 我感到JEP太害怕触摸太多部分了。 但是将有一个非常简单的替代方案它对每个人都好得多 public interface Warning {String name() default warning;String description() default ; } 无需将可能的警告类型的数量限制为有限的常量列表。 相反我们可以使用Warning注释该注释可以包含任何字符串 当然JDK可以具有一组众所周知的字符串值例如 public interface ResultSet {DeprecatedWarning(nameOBSOLETE)InputStream getUnicodeStream(int columnIndex);} 要么… public interface CollectionE {Warning(nameOPTIONAL)boolean remove(Object o); } 注意虽然实际上不赞成使用JDBC的ResultSet.getUnicodeStream() 但我们也可以向Collection.remove()方法添加提示该方法仅适用于Collection类型而不适用于其许多子类型。 现在使用这种方法的有趣之处在于我们还可以增强有用的SuppressWarnings批注因为有时我们只是知道KnowWhatWeAreDoing™例如在编写类似以下内容时 CollectionInteger collection new ArrayList();// Compiler!! Stop bitching SuppressWarnings(OPTIONAL) boolean ok collection.remove(1); 这种方法可以一次性解决许多问题 JDK维护人员拥有他们想要的。 轻度弃用JDK的好工具 关于 SuppressWarnings可能发生的事情的记录不完整的混乱最终将变得更加干净和正式 我们可以根据各种用例向用户发出大量自定义警告 用户可以在非常细微的级别上使警告静音 例如 jOOQ的动机是消除DSL equal()方法与不幸的Object.equals()方法之间的歧义 public interface FieldT {/*** codethis value/code.*/Condition equal(T value);/*** strongWatch out! This is * {link Object#equals(Object)}, * not a jOOQ DSL feature!/strong*/OverrideWarning(name ACCIDENTAL_EQUALS,description Did you mean Field.equal?)boolean equals(Object other); } 此处描述了该用例的背景 https //github.com/jOOQ/jOOQ/issues/4763 结论 毫无疑问JEP 277很有用。 但是它的范围也非常有限可能不会进一步延迟Jigsaw吗但是我希望JDK维护人员可以更彻底地处理生成此类编译器警告的主题。 这是DoTheRightThing™的绝佳机会 我认为上述“规范”并不完整。 这只是一个粗略的主意。 但是我曾希望作为API设计人员多次尝试这种机制。 为了向用户提供有关潜在的API滥用的提示他们可以通过以下方式将其静音 SuppressWarnings 直接在代码中。 易于实现IDE设置。 对于EclipseNetBeans和IntelliJ来说对这些东西实施自定义警告处理将非常简单。 一旦有了Warning批注我们也许可以最后淘汰不那么有用的Deprecated … Warning(name OBSOLETE) public interface Deprecated { }翻译自: https://www.javacodegeeks.com/2015/12/jep-277-enhanced-deprecation-nice-heres-much-better-alternative.html