问题标签 [default-method]

我知道 Inteface 中的所有字段都是隐式的static 和 final。这在 Java 8 之前是有道理的。

但是随着默认方法的引入，接口也具备了抽象类的所有能力。因此非静态和非最终字段也是必要的。

但是当我尝试正常声明一个字段时，它默认变为静态和最终的。

有没有办法在 Java 8 的 Interface 中声明一个非静态和非最终字段。

还是我完全误解了这里的东西？？？

It has generally been the case the Java source code has been forward compatible. Until Java 8, as far as I know, both compiled classes and source have been forward compatible with later JDK/JVM releases. [Update: this is not correct, see comments re 'enum', etc, below.] However, with the addition of default methods in Java 8 this appears to no longer be the case.

For example, a library I have been using has an implementation of java.util.List which includes a List<V> sort(). This method returns a copy of the contents of the list sorted. This library, deployed as a jar file dependency, worked fine in a project being built using JDK 1.8.

However, later I had occasion to recompile the library itself using JDK 1.8 and I found the library no longer compiles: the List-implementing class with its own sort() method now conflicts with the Java 8 java.util.List.sort() default method. The Java 8 sort() default method sorts the list in place (returns void); my library's sort() method - since it returns a new sorted list - has an incompatible signature.

So my basic question is:

• Doesn't JDK 1.8 introduce a forward incompatibility for Java source code due to default methods?

Also:

• Is this the first such forward incompatible change?
• Was this considered or discussed when default methods where designed and implemented? Is it documented anywhere?
• Was the (admittedly small) inconvenience discounted versus the benefits?

The following is an example of some code that compiles and runs under 1.7 and runs under 1.8 - but does not compile under 1.8:

The following shows this code being compiled (or failing to) and being run.

通常承认通过继承扩展接口的实现不是最佳实践，并且组合（例如，从头开始再次实现接口）更易于维护。

这是可行的，因为接口契约强制用户实现所有所需的功能。但是在 java 8 中，默认方法提供了一些可以“手动”覆盖的默认行为。考虑以下示例：我想设计一个用户数据库，它必须具有列表的功能。为了提高效率，我选择用 ArrayList 来支持它。

这通常不会被认为是一种很好的做法，如果实际上想要 List 的全部功能并遵循通常的“组合优于继承”的座右铭，人们会更喜欢：

但是，如果不注意，某些方法，例如 spliterator() 将不需要被覆盖，因为它们是 List 接口的默认方法。问题是，List 的 spliterator() 方法的性能远不如 ArrayList 的 spliterator() 方法，后者已针对 ArrayList 的特定结构进行了优化。

这迫使开发人员

1. 请注意，ArrayList 有自己的、更高效的 spliterator() 实现，并手动覆盖他自己的 List 实现的 spliterator() 方法或
2. 使用默认方法会损失大量性能。

所以问题是：在这种情况下，人们应该更喜欢组合而不是继承，这仍然“真实”吗？

在我的应用程序中，我遇到了一个问题，即当类中的 getter 仅在接口中默认（Java 8 特性）时，结果没有 Java Beans 属性。即对于普通方法调用，它就像标准方法一样工作，但对于通过“属性”访问它突然表现不同......

这是一个测试用例：

结果：

问题：我做错了什么还是Java中的错误？除了从不使用默认方法（对于getter/setter）之外，是否还有其他解决方法，以防您以后可能需要将它们作为“属性”访问？

我一直讨厌 Java “约定俗成的属性”，因为你打错了喷嚏，所以它们往往会被破坏。

正如关于虚拟扩展方法（默认方法）的官方声明所述：

虚拟扩展方法（默认方法）的目的是使接口在初始发布后能够以兼容的方式演进。”</p>

我可以在 JDK 中看到一些很好的例子吗？到目前为止，我已经在java.util.Collection界面和其他几个中找到了，但如果有一个更完整的列表会很好。

编辑：我不是在寻找使用默认方法是否安全（因为我已经阅读了链接的问题）。我一直在寻找 JDK 中的实际示例。

我最近开始使用 Java 8 的 Stream API，我认为这是对 Java 的巨大贡献。但是，我不明白为什么要按原来的方式实施。

Java 8 中其他最精彩的特性之一是接口中的默认方法，它允许对接口进行默认实现。使用这些，Collection 接口可以被赋予通过流 API 提供的所有方法以及默认实现，同时向后兼容。它允许更简单的语法，更像 .NET 中的 LINQ，但也允许实现类型来覆盖这些方法的行为。它将消除每次调用 stream() 方法的需要，以及始终使用 collect() 方法的需要。

我知道这是一个非常普遍的问题，但对我来说，Java 8 的开发人员似乎做出了一个非常不幸的选择，这将很难解决。

考虑下面的例子，

如您所见，SupCls类和Intf接口之间没有联系。但两者都定义了一种通用方法。

并且Testing类正在扩展SupCls和实现Intf。

所以，当我在输出上调用test()方法时，Testing

我认为这是有道理的，因为从类扩展应该比从接口实现具有更高的优先级。

但 eclipse 会报告其他情况，如下面的屏幕截图所示。

我坚信这是Eclipse 中的一个错误。

但在假设之前，这种行为是否在JLS中定义和记录？还是有其他东西定义了这种行为？

编辑：如果重要的话，Eclipse 版本是Mars Release (4.5.0) 。

考虑以下情况，

在上面的示例中，我得到以下输出，这是非常预期的。

我一直在阅读Java-8默认方法，特别是关于扩展包含默认方法的接口

第二个^项目符号：重新声明默认方法，使其抽象。

在上面的示例中，我有两个具有相同名称的默认方法的接口，当我实现这两个接口时，我只能访问其中引用printHello的实现。TestIFace2

我对此有几个问题，

1. 我怎样才能达到的printHello方法，IFace1 如果我不能比为什么？
2. 这种行为不会让我远离预期的性质，IFace1现在可能会被其他方法所掩盖吗？

引用说，您可以在它的子界面中创建该default方法。例如，abstract

在这里，当我实施时，我IFace2实际上无法达到default这种方法，IFace1这正是我的情况。

我有一个接口和抽象类。

我想强制类接口默认方法而不是抽象类。

众所周知，interfacesJava 可以实现多个。它们的实施顺序重要吗？我的意思是，实施 B, C 是否与 C, B in 相同Java 8？我的测试显示顺序确实很重要 - 但任何人都可以解释这背后的逻辑吗？

上面的代码工作正常。如果我将顺序更改B, C为C, B，则会出现错误：The default method display() inherited from B conflicts with another method inherited from C.

编辑

我正在使用 Eclipse（火星）。JDK jdk1.8.0_51. 杰瑞jre1.8.0_60。