随着对默认接口方法的支持越来越接近完成，一些潜在的问题被提了出来。虽然已经完成了很多工作，但这是一个复杂的特性，许多细节问题还没有解决。但首先，这里有一些已解决的问题。
接口允许使用 static 和 const 字段了。
除 == 和!= 之外的操作符也可以在接口中实现。在类中定义的操作符总是优先于接口中定义的操作符，即使接口中定义的操作符更具体。同样，接口中适用的操作符会覆盖基接口中的操作符。
现在，在调用基类方法时可以跳过类了，下面这段话证实了这一点：
我们认为，我们已经批准使用新的 base(Type) 语法，其中，Type 是类类型（例如，跳过一个基类并调用基类的基类），但是我们应该明确地确认这一点。我们还应该确认 base(Type).M() 可能引用一个非虚成员 M。我们还应该确认一个可访问性需求：这个查找找到的 M 必须在调用发生的地方可访问（即通常的名称查找约束）。
在接口中声明受保护方法的特性仍然存在一些疑问，尽管它暂时得到了批准。
当一个类实现了一个方法，但是它的子类将其标记为抽象方法，这被称为“重新抽象（reabstraction）”。这是 Java 互操作性必需的，但是确切的语法仍然没有确定。本质上，问题是是否需要 abstract 关键字。此外，他们“需要确保运行时 [团队] 同意实现重新抽象”。
接口中的普通属性是抽象的，尽管它们看起来像类中自动实现的属性。但是，如果属性是静态的，它就不能是抽象的。这是否意味着在默认情况下，接口中声明的静态属性是自动实现的？
类中的分部方法被认为是私有的，因为它们没有可访问性修饰符。但是在接口中，缺少可访问性修饰符意味着该方法是公共方法。接口中分部方法的规则是什么？它们允许、不允许还是需要 private 关键字？
在默认方法中，object.MemberwiseClone() 是否可以访问？
最后，是否应该将该特性的正式名称命名为 RuntimeFeature.DefaultInterfaceImplementation？答：“LDM 并不关心它的名称。”
本文文字及图片出自 InfoQ
你的反应是：