由于默认方法，JDK 1.8不会为Java源代码引入向前的不兼容性吗？
超类或接口中的任何新方法都可能破坏兼容性。默认方法使接口更改破坏兼容性的 可能性降低
。从默认方法打开向接口添加方法的角度来看，您可以说默认方法可能会导致某些破坏性的兼容性。
这是第一个这样的向前不兼容的变化吗？
几乎可以肯定不是，因为自Java 1.0以来，我们一直在从标准库中继承类。
在设计和实现默认方法时是否考虑或讨论了此问题？ 它记录在任何地方吗？
是的，有人考虑过。请参阅Brian
Goetz在2010年8月发表的论文“通过“公共防御者”方法进行接口演变”：
- 源兼容性
如果修改库接口以插入与现有类中的方法不兼容的新方法，则该方案可能会引入源不兼容性。（例如，如果一个类具有浮点值的xyz（）方法并实现Collection，并且我们向Collection添加一个整数值的xyz（）方法，则现有的类将不再编译。）
（公认的很小的）不便与收益相抵触了吗？
以前，更改接口 肯定会 破坏兼容性。现在，它 可能会
。从“肯定”到“可能”的转变可以被正面或负面地看待。一方面，使向接口添加方法成为可能。另一方面，它打开了您所看到的那种不兼容的大门，不仅与类有关，而且与接口也有关。
但是，正如Goetz论文顶部所引述的，好处大于不便之处：
- 问题陈述
一旦发布，就不可能在不破坏现有实现的情况下向接口添加方法。自从库发布以来，时间越长，此限制对其维护者造成痛苦的可能性就越大。
JDK
7中对Java语言的闭包的添加给老化的Collection接口带来了更多压力。闭包最显着的好处之一是，它使开发更强大的库成为可能。添加一种语言功能以启用更好的库同时不扩展核心库以利用该功能将是令人失望的。
