Observer 在 Java 9 中已弃用。我们应该用什么来代替它？

为什么？这是否意味着我们不应该再实现观察者模式了？

首先回答后半部分——

是的，这确实意味着你不应该再实现和s了。ObserverObervable

为什么它们被弃用 -

他们没有为应用程序提供足够丰富的事件模型。例如，他们只能支持某些事情已经改变的概念，但不能传达任何关于变化的信息。

Alex的回答很好地指出了Observer有一个弱点：所有Observible都是一样的。您必须实现基于的逻辑，并将对象转换为具体类型到方法。instanceofObservable.update()

为了添加它，有一些错误，比如无法序列化Observable类，因为它没有实现接口，而且它的所有成员都是私有的。Serializable

什么是更好的替代方案？

另一方面有很多类型，它们具有回调方法并且不需要强制转换。正如@Ravi在他的回答中指出的那样，你可以改用PropertyChangeListener。Listeners

对于其余部分，已标记了适当的文档，以探索其他答案中链接的其他包。@Deprecation

请注意，弃用也标记了此邮件中所述的分析 -

如今，任何遇到这些情况的人都可能在使用或其他反应流框架时错误地击中了它们。在这种情况下，用户通常希望使用jdk9 API，即所有反应式流框架都应该在计划推出的jdk9兼容版本中兼容/可互操作。RxJavajava.util.concurrent.Flow

编辑：还值得一提的是，API的弃用不仅仅是因为上述原因，而且还无法维护一些错误报告（上面链接）的评论中提到的遗留代码，这些错误报告是为了以一种或另一种方式标记其实现的改进。

还有更多原因：

不可序列化 - 因为，Observable 不实现 Serializable。因此，您既不能序列化可观察性，也不能序列化其子类。

无线程安全 - 这些方法可以被其子类覆盖，并且事件通知可以以不同的顺序发生，并且可能在不同的线程上发生，这足以破坏任何“线程安全”。

提供更少 -

它们没有为应用程序提供足够丰富的事件模型。例如，它们只支持某些东西已经改变的概念，但它们不传达任何关于发生了什么变化的信息。

开放问题 - 如前所述，提出了许多主要问题（线程安全，可序列化），其中大多数都有需要修复的复杂性，并且仍然“未修复”或“没有活动开发”，这就是它被弃用的原因。

我还建议阅读这个答案 为什么应该弃用观察者模式？，@Jeff已经解释了弃用的其他原因。

那么，我们有什么选择呢？

您可以从java.beans package中使用PropertyChangeEvent和PropertyChangeListener。