java - 是否可以在不破坏 Java 的情况下向 Comparable 添加默认方法？

Question

我正在考虑提出一个添加默认方法的功能请求，称为:

default boolean greaterThan(T o) {
    return compareTo(o) > 0;
}

default boolean smallerThan(T o) {
    return compareTo(o) < 0;
}

default boolean atLeast(T o) {
    return compareTo(o) >= 0;
}

default boolean atMost(T o) {
    return compareTo(o) <= 0;
}

到 Comparable界面，因为它会使代码更具可读性 - 在我看来。
但是，我想知道这是否会破坏代码。如果我们添加默认方法，是否有诸如 Lambda 之类的代码会中断？
如果我阅读 this正确地，我会假设 Lambda 至少会继续工作，只要他们不会尝试调用新方法，但我不确定。而且我不知道是否可能存在任何(明显的)其他问题。
请不要讨论可能的功能请求本身。

Answer 1

不幸的是，@BasilBourque 的回答具有误导性，即使它引用了有用的实体。
不可能通过子接口(interface)引入此功能。 SortedMap/NavigableMap 是 不是 适用:default NavigableMap 时机制不存在被介绍了!
此时，可能值得介绍NavigableMap 中的部分或全部方法。如default SortedMap 中的方法, 具有在 sortedmaps 上工作的实现，并且最终将自动被任何已经实现 NavigableMap 的 Map impl 覆盖(因为它们已经覆盖了它们 impl 中的所有这些)。
但是，这意味着“嘿，看看 NavigableMap，它类似于 SortedMap，就像你想对 Comparable 做的一样”是 一个误导性的论点 :您的建议涉及添加默认方法。那只是当时不在桌面上。
最后，您想要的是“几乎但不完全向后兼容”。 Oracle/Java Lang 架构师倾向于说“java 不会破坏向后兼容性”，但这是一个严重的过度简化和边缘谎言。如果你问得更远一点，他们最终会承认这不是真的:问题的核心是 java 权衡任何向后中断的成本(它的可能性有多大，确实破坏它的代码会发生什么？如果它默默地仍然可以编译和运行，但是做错了，这太可怕了，如果重构脚本每次都可以自动应用的微不足道的更新，那就太好了 - 然后混合任何给定代码库偶然发现它的几率，你就有了一个想法'成本')，与它的好处。
这里的成本非常小。任何代码库都极不可能发生故障。但是，如果您想实际提出此功能，那么做一些研究并尝试考虑任何库(或者如果您不能，请查看各种人博客的前 100 个列表，分析例如 github java项目作为源 Material )通过一堆尝试看看发生的事情与.isEmpty这些方法会发生。
然后，有一些坏消息:提出一个 java 特性是极不可能成功的。从某种角度来看，作为 Project Lombok 的作者，他花费数百小时阅读像 lambda-dev 这样的邮件列表，他贡献了大部分实际的 lambda 语法和概念基础，并与多个 Java 语言架构师进行了对话一些长度(主要是在 Java session 上)，我已经发送了一个提案，其中包括 Java 本身的完整补丁，以及 JLS 所需的所有适当更新，它根本没有破坏向后兼容性，而且它从来没有得到任何地方。甚至不如 JEP。
上次我与一位 Oracle 工程师交谈时，他们确实 promise 现在情况会好一些，但这并没有走得太远:我不知道周围或即将出现的任何 Java 特性是由一个局外人提供的在过去的 10 年里，他被直接踢到了 JEP 并接近了 Java 功能的可预见范围。不时有人(通常是 Joe Darcy 或 Alex Buckley)运行一个项目来“添加一堆方便的小语言更改”，例如 Project Coin (那是 11 年前，oof)。对此的第二个看法是Project Amber ，我认为这是一个更连续的项目，而不是具有特定短暂时间跨度的代币。
将其导入 java 的路径大概会通过 amber。